The new website looks better. But will customers still find the page they used before, and will the enquiry reach your team?
A website redesign SEO checklist should protect useful pages, plan changed URLs, check search access and test important customer actions. Agree those responsibilities before approving the design. The new look is one part of the handover.
No checklist can guarantee unchanged rankings. Google's site-move guidance warns that significant moves can cause temporary fluctuations while pages are recrawled and reindexed. Preparation helps you spot avoidable problems and understand what changed.
Use the following as a buyer's review, whether you are redesigning with the current provider or moving to a new team.
First, establish what is actually changing
A visual refresh, a new page structure and a platform migration are different jobs. Ask the provider to identify the changes rather than group everything under “new website”.
- Same pages, same URLs: focus on content, links, page behaviour and search access. A new design does not automatically require new addresses.
- Pages renamed, combined or removed: agree what happens to each useful old address.
- New platform or hosting: check the dependencies around the site, including forms, accounts, analytics and integrations.
- New domain: include the old domain, search properties and redirect arrangements in the plan.
Put the migration work into the budget as well as the launch checklist. Our website redesign cost calculator separates a supported CMS move, changed URL mapping and selected ongoing care, using visible planning assumptions rather than a fixed quote.
For the scope and running budget, see our website redesign cost guide. This checklist addresses a different decision: what needs to survive the change.
The checklist to agree with your provider
| Before approval | What you want to see | Who should own it |
|---|---|---|
| Identify valuable pages | A list of important services, search landing pages and linked resources, with evidence of why they matter. | Your business confirms priorities; the provider reviews the site and data. |
| Decide what happens to old URLs | A mapping of kept, replaced, combined and deliberately retired pages. | The provider proposes it; your team approves business changes. |
| Preserve useful information | The customer questions, service facts and proof that the new pages must still answer. | Both teams, with named approval contacts. |
| Check search access | Intended public pages can be crawled and are not accidentally excluded from indexing. | The provider checks the release configuration. |
| Test customer actions | Enquiries, booking, downloads and any checkout tested through their intended handoffs. | The provider and the person receiving the result. |
| Set the launch decision | A completed check list, outstanding issues and a recovery arrangement. | A named release owner. |
| Check after launch | Live checks, a comparison baseline and an owner for follow-up issues. | Whoever is responsible for ongoing care and search. |
Keep the list short enough to review and concrete enough that “done” means something. A launch task marked “SEO checked” tells you less than a list of important pages and the checks performed on them.
1. Protect pages that already help people find you
Start with the existing search and website data. Which pages get relevant visitors? Which explain your most valuable services? Which are linked from client sites, profiles, emails or campaigns?
Search Console provides search impressions, clicks and query/page information. Website analytics answers different questions about visits and actions. Keep both where available; search clicks are not a complete visitor count.
A page can matter even if its traffic is small. A specialist service page may be more useful commercially than a popular article read mainly by students or tool shoppers. Your provider should understand that distinction before removing or merging content.
Ask for: the priority page list, the data window and the business reason for each important page. Retain the baseline so a later comparison has something concrete to use.
2. Agree changed URLs before they disappear
For every important address that changes, identify its best destination. If the content still serves the same purpose, keeping the existing URL may be the simplest choice.
For a permanent move, Google recommends a permanent redirect. It lets people and search engines reach the replacement. A redirect does not make an unrelated destination answer the old customer's question.
Consider a hypothetical service page, /services/bookkeeping, replaced by /services/monthly-bookkeeping. The useful handoff is to the matching new service, with its scope and contact path intact. Sending every old address to the homepage loses that context.
Ask for: an old-to-new URL map, a reason for removed pages and checks of the important redirects. Also ask who maintains the redirects and the old hosting/domain arrangements after handover. A migration task is not complete just because the new site loads.
3. Check the answers, not just the layout
Read the new service page as a prospective customer. Can you still find what the business does, who it fits, the evidence and the next step?
A redesigned page may lose useful content when a long section becomes a decorative card. It can also improve when repetitive text is replaced with a direct answer. Judge the result against the buyer's decision rather than trying to preserve every old sentence.
Check these together:
- The visible heading and page title describe the same useful topic.
- Service details, prices and business claims have an owner who approved them.
- Relevant internal links lead to the right guide, service or proof.
- Images, downloads and contact details still make sense in their new context.
Google's title guidance recommends descriptive titles and may use several page signals when generating the search title. A title is a promise to the visitor, not a guarantee of a particular snippet.
Ask for: an agreed review of the most important pages, including what was intentionally changed. An approved design file alone does not establish that the finished content is correct.
4. Keep preview settings out of the public release
A preview site may be kept out of search while it is being built. Before launch, check the intended public version and its important pages.
Google distinguishes blocking crawling from preventing indexing. A crawler needs access to a page to see its noindex rule. These settings require deliberate review rather than a blanket “allow everything” change.
Keep intentionally excluded pages excluded. For pages meant to appear in search, check that preview-only restrictions have been removed and the preferred page address is correct. The canonical URL should describe the intended public version, rather than the staging address.
Ask for: checks on live page responses and metadata after release. Screenshots of the design cannot demonstrate indexing settings.
5. Test the enquiry all the way through
A contact button can look correct while its next step fails. Test the form confirmation, the receiving process and any booking handoff, with a clearly identified test enquiry agreed by the people involved.
On a phone, check that someone can read the important information, use comparison tables, complete the form and find the booking control. Test the actual route rather than only checking that a button exists.
If your business uses analytics, confirm which events represent a button click, an accepted enquiry and a confirmed booking. Treat them separately. A visitor opening the calendar is useful behaviour, but it is not a booked meeting.
Ask for: confirmation of what was tested, where the result went and who will investigate failures. Access and credentials should be shared through an agreed process, not pasted into the initial project enquiry.
6. Name the owner after launch
Before the release, agree who handles an urgent problem and what coverage applies. Keep a recovery plan appropriate to the platform, with a person authorised to use it.
Afterwards, review live access, the important old URLs and customer actions. Compare complete, comparable reporting windows rather than drawing conclusions from launch-day traffic. Account for campaigns, seasonal demand and changes in the countries or queries bringing visits.
Investigate a missing page, failed enquiry or accidental indexing restriction promptly. Give normal search fluctuations their own evaluation instead of assuming every drop proves the redesign failed.
If the team handling the build will not handle ongoing work, our website maintenance and support service explains how a takeover and responsibility plan can fit. Continuing care and a new design should have a clear handover between them.
A short brief you can send before approving the project
We want the new website to explain our current offer without losing useful existing pages or breaking customer enquiries. Please identify the important pages, any changed URLs and their destinations, the search-access checks, the enquiry/booking tests and who owns issues after launch. Separate these responsibilities from the design approval and show what is included in the quote.
Add your current site, the business changes and the pages you already know matter. That gives a provider a useful starting point without asking you to write a technical migration specification.
Ekyon's website redesign and managed care service can scope the content, build, relevant migration work and ongoing responsibilities together. We review the current site before deciding what needs to change. For delivered website scope, inspect Dosawala or Bomoz; those cases do not establish a measured migration or ranking result.
Frequently Asked Questions
You can plan to reduce avoidable problems by reviewing useful pages, changed URLs, search access and content before launch. No provider can guarantee unchanged rankings; significant site moves can cause fluctuations while search engines process the changes.
A visual redesign does not automatically require redirects. Review any changed, combined or retired addresses separately, and use suitable destinations for permanent moves.
Important pages and a baseline, an old-to-new URL plan where needed, useful content and links, search-access checks, enquiry and booking tests, a release owner and an ongoing review plan.
No. A migration is a defined change project, while maintenance is continuing responsibility for agreed website work. Confirm who handles launch issues, ongoing care and any search follow-up, rather than assuming one fee covers all three.
Planning a redesign or changing providers?
Share your current site, the planned change and the pages or customer actions you want protected. We will discuss the scope and who should own the handover.
Want to hand over the website work?
Explore Ekyon's redesign, maintenance and search scope, with real website work and a clear responsibility plan.
