A redesign changes the experience. A migration changes where or how the site is served. A project can involve both, but a new appearance is not evidence that the move has preserved the content, search foundations or inquiry path your business depends on.
Begin with a short written scope: what needs to improve, what must survive, who supplies the inputs and how you will accept the result. This applies to a startup replacing its first site, a service business improving its inquiries or a professional practice moving an established website. The plan should reflect the business and platform rather than a list of pages copied from another project.
Decide whether the first purchase is diagnosis or delivery
If the problem is unclear, start with a scoped website or search audit. Its output should identify findings, supporting observations, priorities and a recommended remediation scope. An audit does not include the fixes unless the agreement says so.
If the problem is already understood, define the delivery directly. That may be a focused repair, clearer service content, a new inquiry route or a full redesign. A rebuild is not automatically the right answer to weak inquiries or a search decline. First separate content and usability issues from indexing, demand, tracking and operational problems.
Our websites and search service covers these different starting points. A useful initial scope can stand on its own and leave later growth work as an explicit next decision.
Inventory what must survive
Before changing the live site, assemble an inventory the team can review:
- Pages and URLs. Record existing public addresses, important linked documents, page purpose and the intended disposition: retain, improve, move or remove.
- Useful content and evidence. Identify approved copy, original media and material that needs correction or permission. Confirm who will approve factual and commercial statements.
- Visitor tasks. Include service discovery, navigation, mobile use, contact, booking and any essential account or purchase journey.
- Integrations and access. Record forms, mail delivery, scheduling, analytics and other connections, together with their owners. Transfer access through an approved process; do not send passwords in a project brief.
- Search and measurement. Preserve available baseline records, current canonical destinations and sitemap behavior. Keep search visibility, inquiries and revenue as separate measures.
The result is a preservation plan, not a promise that every old page deserves a new version. Retain what is useful, and make each material removal an informed decision.
Map old addresses to useful destinations
Keep an existing URL when it still represents the same useful page and there is no reason to move it. Where a permanent move is necessary, record the old address and its relevant new destination in a redirect map.
Check the actual response and final destination for each important old address. Avoid redirect loops, unnecessary intermediate hops and sending unrelated removed pages to the homepage. When there is no suitable replacement, choose and record the removal behavior instead of inventing an irrelevant equivalent.
Include linked files and alternate host or path forms where they matter. Update internal links to the intended destination. A redirect list in a spreadsheet is preparation; working behavior on the served site is the acceptance evidence.
Agree the content and search work explicitly
A redesign proposal should name the pages and what each one helps a visitor decide. Give important services substantive answers: who the work is for, what is delivered, what is needed from the buyer, where the boundaries sit and how to start.
Technical search foundations belong in the scope too: descriptive page titles, useful headings, production canonicals, crawl and indexing controls, sitemap entries and accurate structured data where appropriate. Verify them on the release candidate and again on the public site. A development environment should not become an accidental search destination.
Going national or entering another market needs more than replacing a city name in identical copy. Assess the service, language, inquiry handling and business's ability to deliver in that market. Publish distinct location or language content only when it is useful and supportable; do not imply offices or local operations that do not exist.
Search foundations make the site easier to understand and evaluate. They do not guarantee crawling, indexing, rankings or business demand. Google Search Console observations and submitted indexing requests are separate from those outcomes.
Make the inquiry path part of acceptance
Walk through the task a prospective customer actually performs. Can they understand the offer, find a relevant next step and submit an appropriately short inquiry without disclosing sensitive records?
Agree checks for required and optional fields, invalid input, duplicate submission, pending state, provider failure and the accepted state. Preserve entered information when a request fails. Test the destination and its responsible owner through an authorized method, using synthetic data where possible.
Keep the evidence precise. Application acceptance does not by itself prove receipt in a human inbox, a qualified opportunity or a booked appointment. An embedded calendar loading is not a completed booking. Record which layer was actually checked and leave the others open until verified.
Put ownership and ongoing costs in writing
Identify who controls the domain, hosting, source code, content, analytics and connected accounts. Agree the handover materials and the access the business needs to operate or leave the arrangement.
Separate a project from its ongoing services. Hosting does not automatically include content production, search improvement, integration support or recovery coverage. Name update responsibilities, support hours, exclusions, third-party charges and the process for requesting changes.
The main scope drivers are the existing site's condition, page and content work, platform constraints, integrations, migration risk, review effort and launch responsibilities. A staged project may be more useful than one large replacement. The engagements page explains the available structures, including selected reduced-upfront, revenue-based arrangements whose terms are agreed individually.
Define the launch decision before launch day
Write a finite acceptance record covering the page set, content approval, important old URLs, navigation, mobile layouts, keyboard access, inquiry behavior, metadata and the agreed performance checks. Record material exceptions and who decides whether they block launch.
Retain a practical recovery path for the existing site and configuration. Name the person who authorizes publication and the person who verifies the served result. Agree how an issue will be reported and addressed after the change.
After publication, verify the actual public source and visitor paths. Reconcile sitemap and search-console work with the live release, and monitor observations over an agreed period. A successful build, a green deployment indicator or one HTTP response does not complete the business acceptance.
A useful brief is enough to start
Bring the current URL, the business goal, the parts that are working, the problems you can observe and any deadline that matters. Note who owns the content and connected systems. You do not need to select a platform or finish the migration map before an introductory conversation.
Explore websites and search for growing businesses, see how we scope and accept delivery, or discuss your project. If the website also needs an AI feature or internal system connection, use the build versus buy guide for that separate decision.