Define the move before choosing a launch window
Write down exactly what will change: platform, hosting, domain, page addresses, content or design. A platform change with identical public addresses needs different checks from a move that replaces every product address. Keeping the domain does not mean the URLs stayed the same.
Where practical, separate the platform migration from a major rewrite or rebrand. Google recommends changing things in stages. Agree which changes are essential now and put optional improvements into a later task list.
Create a shared launch document. Name an owner for content, redirects, infrastructure, analytics and approval. Give each task an acceptance check and a person who can fix it. For an agency handoff, specify who remains available after launch and who controls the accounts. A checklist without owners is just stationery.
Build an inventory and save a baseline
Combine a crawl of the existing site with CMS exports, XML sitemaps, search landing pages and available server logs. Compare the lists rather than assuming the navigation contains everything worth moving. Include downloadable files, images, campaign pages and pages that other websites link to.
Save Search Console performance exports and analytics reports before making changes. Search Console describes visibility and clicks from Google; analytics describes activity on the website. Record the reporting filters so you can repeat the comparison later. Keep enquiries and purchases alongside traffic figures.
Mark business-critical pages explicitly. A specialist service page with modest traffic may matter more to the business than a popular article. Give those pages individual review tasks instead of relying only on template sampling.
- Record each current address, page type, title, main heading and intended indexing status.
- Capture canonical targets, internal links and language alternatives where present.
- Assign a proposed destination, content owner and migration decision.
- Save screenshots and exports outside the platform being replaced.
Give every old page an explicit destination
Build a redirect map before importing content. Use a spreadsheet with separate fields for the old address, new address, decision, implementation status and test result. Preserve existing addresses when they still make sense and the destination platform supports them.
Review the map with someone who understands the content. Similar page names do not necessarily mean the pages answer the same question. If several articles are combined, check that the replacement actually covers their useful material. Avoid sending unrelated retired pages to the homepage; Google may treat irrelevant redirects as soft errors.
The table below is a decision guide. Store the actual addresses in your working migration sheet, then test the deployed behaviour against that sheet.
| Content decision | Expected behaviour | Acceptance check |
|---|---|---|
| Keep the page and its address | Serve the intended content successfully | Content, metadata and navigation remain correct |
| Move a page permanently | Use a server-side 301 or 308 redirect | The old address reaches the matching replacement |
| Merge overlapping pages | Redirect to a relevant consolidated page | The replacement answers the original visitor's need |
| Remove content with no replacement | Return 404 or 410 | A useful error page appears with the correct status |
Prove the destination can handle the migration
Before committing to a platform, ask the implementer to demonstrate redirects, metadata editing, canonical controls, sitemap output and handling of missing pages. Use examples from your inventory. A feature checkbox is less useful than seeing your awkward legacy page work.
Run a trial import containing different content types. Include a long article, a service page, a product with variants if relevant, a download and a translated page. Compare the imported fields against the originals. Decide how unsupported fields will be stored or rebuilt before importing the full collection.
Export existing redirect rules too. An address from an earlier redesign may still receive visits. Carry those mappings into the new system and point them directly to the final destination. Test rule precedence, letter case, trailing slashes and query parameters against real examples from your inventory.
Keep staging private and make launch settings explicit
Use access restrictions for a staging environment that should remain private. If public test pages use noindex, remember that Google must be able to crawl a page to see that instruction. Blocking crawling through robots.txt does not reliably keep an address out of search results.
Document the production settings separately. At launch, public pages intended for search must be accessible without staging passwords or accidental noindex instructions. Check both page metadata and HTTP response headers. Keep intentional restrictions for account pages and other non-public areas.
Ask for evidence from the actual production deployment, not just a screenshot of a CMS setting. Test representative pages and their shared templates. A setting can look correct in an editor while a server, plugin or deployment configuration sends something different.
Compare content and search signals on the new templates
Review old and new pages side by side. Preserve useful copy, headings, images, descriptive alternative text and downloads unless a change was approved. Check that a page still answers the same question and offers the same next step. Record deliberate omissions so they are distinguishable from import errors.
Check canonical tags, which indicate the preferred address for duplicate or very similar content. They should agree with internal links and sitemap entries. A production page should not name a staging address as its preferred version. Canonical tags are signals to Google, not instructions that force its choice.
For English, French or regional page variants, preserve the relationships between equivalent pages. Update hreflang references to the final destinations and check reciprocal references. Do not accidentally collapse every language into the English page.
Review structured data against the visible content. Use Google's Rich Results Test for supported types and investigate errors. Valid markup can support eligibility for enhanced search appearances, but does not promise that Google will display them.
Test rendering, links and customer tasks
For a JavaScript-driven build, check rendered content rather than assuming a page that works in your browser is ready for search. Google processes JavaScript, but rendering can encounter problems. Inspect important text, metadata and navigation in the rendered output. Navigation should use crawlable links with real destinations.
Give the reviewer a task script: arrive on a service page, follow a related page, submit an enquiry and confirm receipt. For a store, include search, product selection, basket, checkout and confirmation using an appropriate test setup. Check the resulting records as well as the success message.
Repeat essential tasks on mobile and with a keyboard. Compare loading behaviour under consistent test conditions and investigate new delays or layout movement. These checks belong beside the SEO review: preserving visits has limited value if visitors cannot finish what they came to do.
Rehearse the cutover and define when to stop
Write the launch sequence before launch day. Include the final export, content freeze, import, redirect deployment, production configuration and verification. For a store or membership site, decide how orders, accounts and edits created during the transfer will be reconciled. Avoid leaving that decision to whoever notices first.
Keep a restorable backup and rehearse the recovery procedure. Assign authority to pause or reverse the launch. Define concrete stop conditions: widespread missing pages, inaccessible checkout, broken forms or public pages blocked from indexing.
If hosting changes, review DNS and preserve unrelated records, including those used by email. Keep the old infrastructure available until the new service is working and traffic has moved. A rollback also needs a data plan: restoring an older database must not silently discard activity recorded after launch.
Stop the launch if an important redirect reaches the wrong page, checkout or enquiries fail, production is still blocked from indexing, or the final data import cannot be reconciled. Resolve the failure and repeat the relevant checks before cutover. If new orders have reached the destination, any fallback must account for those writes; reverting the old database is not a safe substitute for a data-aware recovery plan.
- Confirm access to the registrar, DNS, hosting, CMS and reporting accounts.
- Verify the backup can be restored and the previous configuration is recorded.
- Confirm HTTPS works on the production destination.
- Assign someone to test customer tasks immediately after the switch.
- Record the final launch decision and any unresolved issues.
Run the launch checks against the live site
Request every old address in the migration map and compare the result with the expected behaviour. Check the response status, redirect destination and final content. Avoid loops and unnecessary redirect chains. A redirect reaching a working but unrelated page still fails the review.
Crawl the new site and repair links that still point to old destinations. Generate a sitemap containing the intended canonical addresses and submit it in Search Console. Sitemap submission helps discovery; it does not ensure indexing.
Confirm Search Console ownership remains valid and inspect important live pages. If the domain changes, follow Google's site-move guidance for the Change of Address tool. A platform change that retains the domain and addresses does not need that notification.
- Check the homepage, important landing pages and every major template.
- Verify titles, canonical targets, indexing instructions and sitemap contents.
- Check an intentionally missing page returns an error status rather than a successful response.
- Submit a test enquiry and verify the expected analytics event.
- Save crawl results and launch notes for the monitoring owner.
Monitor patterns and investigate before changing more
Compare search clicks, impressions and landing-page activity with the saved baseline. Use comparable periods and account for seasonal demand. Group results by page type, country and device where useful. A site-wide total can hide a problem isolated to products or French-language pages.
If analytics falls while Search Console clicks remain steady, inspect tracking before concluding that rankings fell. If both decline for a group of pages, inspect those destinations, their redirects and indexing status. Review server errors and Search Console reports for supporting evidence.
Keep a log of issues, fixes and subsequent observations. Avoid making several speculative changes at once. Maintain old-address redirects and, for a domain move, retain control of the old domain. Agree who owns redirect maintenance after the migration project closes; cancellation of an old service should not quietly remove the route to the new site.
How hehe.software can help
hehe.software is a small, independent web and app studio based in Vancouver, British Columbia, working remotely across Canada and the United States. We offer website migrations, technical SEO, integrations and fixes on sites we did not build. We can scope a complete migration or take a defined sub-project for an agency. Start with the contact form or email mwe@hehe.software with your current platform, intended destination and critical customer tasks. We scope the work and provide a fixed quote or an hourly estimate.