The short answer
Before launch, inventory existing pages, approve old-to-new URL decisions, test redirects and important content, and verify indexing controls and analytics. After launch, repeat those checks on the live site and compare equivalent page groups—not just sitewide traffic. My recommendation: postpone launch if important pages are inaccessible, redirect destinations are wrong, or customer inquiries cannot reach you.
The design changes, but page addresses stay the same
Check: Compare content, navigation, indexing settings, and inquiry forms
Next: Keep useful URLs; test template changes rather than inventing a redirect project.
The domain, platform, or URL structure changes
Check: Require a destination or removal decision for every inventoried URL
Next: Approve the mapping and test the actual redirect rules before launch.
Visits appear to fall immediately after launch
Check: Compare analytics collection, Search Console data, and live page access
Next: Separate measurement failure from lost search visibility before changing content.
Traffic holds steady, but inquiries disappear
Check: Submit forms and inspect delivery, consent behavior, and recorded events
Next: Repair the customer journey and measurement separately.
Decide what is changing—and who can stop the launch
Start with a change register: domain, hosting, platform, page addresses, templates, content, and analytics. A visual redesign can remove useful text or navigation without changing a single URL. Conversely, moving servers does not justify renaming pages. I recommend keeping each change tied to a business reason and an acceptance test, so “the new site looks finished” does not become the only launch criterion.
Name the person who approves content removals, the developer responsible for deployment, and the person authorized to delay launch. Agree how backups will be restored and how orders or inquiries received after deployment will be preserved if a rollback becomes necessary. Technical SEO support can cover the search-related checks; specialist development should remain coordinated with your developers. This checklist is a recommended acceptance process, not a Google-mandated project plan.
Build an inventory that explains what matters
Combine a crawl—a tool following the site’s links—with the content management system’s export, XML sitemaps, Search Console landing pages, and available external-link records. No single list is complete. A page missing from navigation may still attract customers. Record each URL’s page type, search visibility, attributable inquiries or sales where measured, incoming links, and planned treatment: retain, move, merge, or remove.
Save dated exports and examples of important pages before deployment. Include page titles, main content, navigation, indexing settings, and analytics definitions. Compare several representative weeks and, where useful, the equivalent seasonal period; one unusually busy day is a poor baseline. Separate service pages, categories, articles, and language versions. If commissioning a review, specify these files in the SEO audit deliverables, rather than accepting only a presentation of findings.
- Give pages with measured business value or valuable external links individual review.
- Keep low-traffic but essential pages, such as specifications or location information, in the inventory.
- Mark missing evidence as unknown; do not treat an empty analytics cell as proof that a page is useless.
Map pages by customer need, not matching words
Google’s site-move guidance supports permanent server-side redirects for moved URLs, discourages irrelevant mass redirects, and recommends keeping redirects for at least a year. For eligible domain moves, it also describes Search Console’s Change of Address process. These are technical migration practices, not assurances that search visibility will remain unchanged.
Illustrative example: a hypothetical commercial refrigeration repair business is rebuilding its site. The table uses page labels, not actual addresses. In the working spreadsheet, record exact old and new URLs, the reason for each decision, and a reviewer. A successful redirect test must establish that the destination answers the old page’s customer need—not merely that some page opens.
| Existing page | Proposed destination | Decision | Acceptance evidence |
|---|---|---|---|
| Emergency freezer repair | Renamed emergency repair page | Permanent redirect | One redirect reaches an accessible page retaining emergency-service details. |
| Two overlapping maintenance articles | Combined maintenance guide | Merge, then redirect both | The guide retains the distinct useful instructions from each article. |
| Discontinued equipment sales | General repair homepage | Reject proposed redirect | With no relevant replacement, return 404 or 410 and offer useful navigation. |
| Walk-in cooler servicing | Same page address | Retain without redirect | The page remains accessible with its service description and inquiry route. |
Check what the new templates actually publish
A canonical tag identifies a preferred URL among duplicate or very similar pages. Google treats canonical declarations as signals, not binding instructions. Redirects, internal links, and sitemap entries should support a consistent preferred version. A canonical tag is not a replacement for moving visitors from an old address.
My template review would compare rendered pages, not just editor fields: can visitors see the service details, headings, images, and contact options that were approved? Check that public pages do not retain a noindex instruction, which requests exclusion from search. Verify structured data against visible content. For multilingual sites, test language switching and hreflang annotations, which identify language or regional alternatives. Consult international keyword research before consolidating language pages that may serve different customer needs.
Ask for test evidence, not a checked box
Protect the staging site—the private test copy—with access controls. A robots.txt crawl restriction alone is not privacy protection. Test the proposed production configuration separately so staging protections are not copied onto public pages. Request dated results showing the tested address, expected behavior, actual behavior, owner, and retest status. An unresolved failure needs a decision, not a green project dashboard.
For WordPress, inspect permalink settings, SEO plugin output, redirects, caching, and the search-engine visibility setting. Two plugins can produce conflicting output even when their individual settings look reasonable. The WordPress SEO audit checklist provides a broader review; WordPress SEO support is relevant when those checks need implementation. Test representative mobile pages and the actual inquiry process, including confirmation and message delivery.
- My launch blockers: important pages fail to load, public templates carry unintended noindex, key redirects lead to unrelated pages, or forms fail.
- Documented follow-ups: minor formatting issues or nonessential metadata gaps with an assigned owner.
- Evidence to retain: redirect test export, template comparisons, approved removal list, and successful form-delivery confirmation.
Repeat critical tests on the live site
Passing staging tests does not prove that production works. Domain routing, security certificates, server rules, and caches can behave differently. At deployment, test important old addresses from outside the admin session. Confirm their destinations, the live content, and the absence of unintended access restrictions. Check both the initial server response and the page visitors receive.
Verify Search Console access for relevant properties, submit the current sitemap, and inspect representative new URLs. Confirm that internal links reach final destinations directly. Run a real test inquiry and check analytics with the appropriate consent state; a recorded button click does not prove message delivery. Keep a dated release log of fixes. For serious availability failures, evaluate rollback against the agreed recovery plan rather than improvising from traffic charts.
Diagnose the pattern before choosing the repair
Review technical failures promptly after release, then monitor search and business measures on a schedule proportionate to site activity. Compare old and new addresses together when judging a moved page: declining visits to the old URL alone do not establish a loss. Group results by page type, language, and device, and account for reporting delays and demand changes.
If analytics visits fall while Search Console clicks remain broadly stable, investigate measurement first. If one template group loses visibility, check its redirects, content, and indexing settings. If visits remain stable but inquiries fall, test forms and the offer itself. Record each hypothesis, supporting evidence, fix, and retest. The organic traffic drop diagnostic helps extend that investigation. Avoid reversing a migration solely because of a single day’s rankings.
Common questions
Do unchanged URLs need redirects during a redesign?
No, not simply because the design changes. Keep an unchanged page directly accessible. Still test its content, internal links, indexing controls, and forms: retaining the address does not preserve everything else.
Can this checklist guarantee no traffic loss?
No. It helps expose avoidable implementation errors, but search engines still need to process changes. Demand, competition, and content changes can also affect performance. Agree on monitoring and repair responsibilities rather than a guaranteed outcome.
When should SEO checks begin?
Before URL structures, templates, and content removals are finalized. If development is already underway, begin with the inventory and high-value page mapping. Late involvement is still useful, but may reveal changes that require rework before launch.