A redesigned website can pass its visual review while an old service page returns an error. Visitors following bookmarks or search results still arrive at those addresses, even after the navigation has changed.
Managing site migration and SEO requires a separate approval process: a record of what needs preserving, who implements the changes and what evidence confirms the site is ready.
Define the changes and assign responsibility
Start with the scope. A hosting move with unchanged public URLs does not automatically require redirects. Changing platforms might alter every page address, while a visual redesign can keep URLs intact but remove useful content or navigation links. Each calls for different checks.
A business working with a Cheshire SEO agency should put the developer’s implementation tasks and the agency’s review tasks in the same brief. The owner or marketing manager approves decisions about services, content removal and launch timing.
For every essential task, record a named person, a deadline and a test result. A “done” label tells the next person little about what was checked.
Record the pages and content worth preserving
Build an inventory of existing URLs before the old site is replaced. Combine a website crawl with existing sitemaps and Google Search Console data to capture pages beyond those visible in the main navigation.
Mark each page as staying, moving, merging or being retired. Prioritise important service pages, pages receiving organic visits and URLs linked to by other websites. A specialist service page may attract few visits yet still answer questions customers need resolved before enquiring.
Save the content and page titles being retained, along with a dated performance baseline for later comparison. The owner approves the proposed changes; the SEO reviewer checks that valuable pages are accounted for. Resolve disagreements here, before they become launch-day decisions.
Give changed URLs a relevant destination
For permanently moved pages, the developer should implement permanent redirects, commonly using a 301 response. These send visitors and search engines from an old address to its replacement.
Suppose `/boiler-repairs/` becomes `/services/boiler-repairs/`. Redirect the old address directly to the new repair page. Sending it to the homepage leaves visitors searching again. When several pages are combined, choose a destination that genuinely covers their subject matter.
Ask for test results showing each old URL, its intended destination, the redirect response and the final page response. Check for broken destinations, loops and unnecessary chains through intermediate addresses.
URLs for genuinely retired content without a relevant replacement should return an appropriate not-found response. Record that decision so an intentional removal is distinguishable from an accidental omission.
Set the checks that must pass before launch
Agree approval criteria before committing to a launch date. Test the development version, often called staging, and record which checks must be repeated immediately on the public site.
The reviewer should confirm three essentials:
- Pages intended for search will be accessible on the live site, without accidental crawling blocks or `no index` directives.
- Internal links use the intended live addresses. Canonical tags indicate the preferred page URLs, and XML sitemaps list the appropriate live URLs.
- Important content, page titles and redirect destinations match the approved plan, with outstanding issues documented.
Robots.txt restrictions control crawling; `no index` concerns indexing. Keep those checks separate and retain legitimate exclusions where needed.
Missing priority pages, widespread broken redirects and accidental sitewide indexing restrictions should block launch. Minor presentation changes can wait on an agreed improvement list.
Before release, ask the developer to confirm backup and restoration arrangements, including who can authorise action if serious problems arise. Base launch approval on the recorded test results.
Keep responsibility clear after launch
Repeat the essential tests on the public website, where settings and behaviour can differ from staging. Check important old URLs, destination pages and navigation links again. Confirm that analytics records visits before interpreting traffic changes.
Use Search Console to investigate priority URLs and monitor indexing, alongside comparable pre-launch performance data. Loading in a browser and appearing in Google’s index are separate checks. Log problems against specific URLs, with enough detail for the developer to reproduce them.
Search visibility can fluctuate while a migration is processed, with no universal stabilisation deadline. Investigate technical faults promptly rather than treating every decline as temporary.
The final handover should contain the approved URL map, test results, outstanding issues and named post-launch contacts. Agree who checks performance, who fixes faults and when the team reviews progress.
