Website Redesign SEO Checklist: Key Takeaways
- Bring SEO, content, development, analytics, accessibility, and business owners into the project before templates and URLs are finalized.
- Record a baseline by page and page type; a sitewide traffic total is not specific enough to diagnose a migration.
- Give every existing URL an explicit disposition: keep, move, merge, or retire.
- Use a relevant permanent server-side redirect when a page has permanently moved; do not send unrelated retired URLs to the homepage.
- Preserve the purpose and useful information of high-value pages, not merely their title tags or visual layout.
- Test production-like rendered pages, navigation, structured data, forms, analytics, and index controls before launch.
- Define launch stop conditions and a rollback owner in advance.
- Monitor search visibility and conversions together because stable traffic can still hide a broken lead path.
First, Classify the Redesign Risk
“Redesign” can describe anything from new colors to a complete domain and platform move. Start by naming the changes instead of treating every project as equal.| Change type | Examples | Primary risks to control |
|---|---|---|
| Presentation refresh | Brand colors, typography, spacing, components | Hidden or removed content, heading changes, accessibility, layout shift, slower assets |
| Template redesign | New service, location, article, product, or lead-form templates | Repeated metadata, lost structured data, changed internal links, missing calls to action |
| Information architecture change | New navigation, categories, folders, or internal-link system | Orphan pages, changed crawl paths, weak topic relationships, breadcrumb errors |
| URL migration | New slugs, folders, HTTPS migration, or domain change | Missing or irrelevant redirects, chains, conflicting canonicals, outdated links and sitemaps |
| CMS or hosting migration | WordPress rebuild, replatforming, server or rendering change | Different HTML output, index-control mistakes, server errors, performance and feature parity |
| Content consolidation | Removing, combining, rewriting, or repositioning pages | Lost intent coverage, cannibalization, poor destination matching, disappearing backlinks or conversions |
Create a Change Budget
A change budget is a simple record of what the project must change, what it can preserve, and what should wait. It prevents a redesign from quietly becoming a domain move, content rewrite, navigation overhaul, analytics replacement, and rebrand on the same launch day.| Field | Question to answer |
|---|---|
| Required change | What business or user problem requires this change now? |
| SEO surface affected | Will it alter URLs, copy, headings, links, rendering, structured data, or indexability? |
| Evidence to preserve | Which queries, pages, backlinks, conversions, or user tasks already work? |
| Owner | Who approves, implements, verifies, and reverses the change? |
| Rollback unit | Can this component be restored without reversing the entire launch? |
| Deferred work | Which desirable changes can safely wait until the migration stabilizes? |
Score the Migration Before Choosing the Controls
A risk score does not predict a ranking loss. It gives the team a repeatable way to decide how much baseline data, testing, monitoring, and rollback preparation the project needs. Score each factor from 0 to 3, then record the evidence behind the score. The maximum is 18.| Factor | 0 points | 1 point | 2 points | 3 points |
|---|---|---|---|---|
| URL change | No production URLs change | A small, isolated set changes | Folders or many slugs change | Domain, protocol, or most URLs change |
| Content change | Substantially preserved | Minor edits to a few templates | Major rewrites or consolidation | Intent, offer, or topic coverage is rebuilt |
| Platform and rendering | Same CMS and rendering | Theme or component change | CMS, framework, or hosting changes | Several infrastructure layers change together |
| Architecture and links | Navigation and links stay stable | One navigation area changes | Taxonomy or internal-link rules change | Site hierarchy is comprehensively replaced |
| Business dependence | Organic search is noncritical | Search supports awareness | Search produces meaningful leads or revenue | Core acquisition or operations depend on it |
| Recovery readiness | Tested rollback and named owners | Backup and owners exist | Recovery steps are incomplete | No verified backup, rollback, or authority |
Build a Baseline That Can Explain What Changed
A baseline should help answer a future question: which page, query group, template, audience, or conversion path changed after launch? A screenshot of total organic traffic cannot answer that on its own.
Inventory the Existing Site
Combine sources rather than trusting a single crawl. A crawler can miss orphan pages; an XML sitemap can contain noncanonical URLs; analytics can omit pages with broken tracking; and Search Console may contain historical URLs that are no longer linked. Gather URLs from:- the current crawl and XML sitemap;
- Google Search Console landing-page and link data;
- web analytics and conversion reports;
- backlink data, paid campaigns, email links, profiles, and important referrals;
- the CMS, media library, downloadable files, and any separate subdomains;
- server logs when they are available and useful for a larger or technically complex site.
Create a Critical-Page Register
Flag pages that matter for different reasons. A low-traffic contact or confirmation page may be business-critical. A research article may have valuable links even if it does not convert directly. A service page may generate leads from a small but qualified query set.| Evidence type | What to record | Why it matters after launch |
|---|---|---|
| Search demand | Queries, clicks, impressions, average position, country, and device where relevant | Reveals whether a specific intent or audience was lost |
| Business value | Qualified forms, calls, bookings, sales, assisted conversions, or other agreed actions | Separates visibility from commercial performance |
| Authority | Meaningful external links, internal links, citations, and referral sources | Identifies URLs that should not disappear without a relevant plan |
| Page purpose | Audience, intent, key answer, proof, primary call to action, and relationship to other pages | Prevents a redesign from preserving a URL while removing what made it useful |
| Technical state | Status code, canonical, index directive, title, H1, structured data, hreflang, render state | Supports a direct old-versus-new comparison |
| User experience | Core task, form path, navigation path, accessibility issues, and performance baseline | Finds redesign losses that ranking reports cannot show |
Give Every Existing URL a Disposition
A redirect spreadsheet should not begin with the assumption that every URL must change. First decide what should happen to the page and why. Use four clear dispositions.| Disposition | Use when | Required action |
|---|---|---|
| Keep | The URL and page purpose remain valid | Retain the URL, preserve or improve useful content, and verify self-referencing canonical and internal links |
| Move | The same page has a necessary new URL | Map old to new, use a permanent server-side redirect, and update internal links and canonical references |
| Merge | Several pages serve the same intent and one stronger destination will replace them | Combine genuinely useful material, choose the best destination, redirect retired URLs, and remove conflicting internal links |
| Retire | The page has no relevant replacement and no continuing user, search, link, legal, or business need | Remove internal links and sitemap entries, preserve required records, and return an appropriate not-found or gone response |
Choose Redirects by Meaning, Not Convenience
For a permanent URL move, Google recommends a permanent server-side redirect such as a 301 or 308 when possible. Permanent redirects are a signal that the destination should become canonical. Temporary redirects serve a different purpose and can keep the source URL as the intended search result. See Google’s current redirect guidance. A good redirect answers: “Where would a visitor reasonably expect this exact page or its consolidated replacement to be?” Sending many unrelated pages to the homepage can confuse users and may be treated as a soft 404. Redirect directly to the final destination rather than creating avoidable chains.Align Canonicals, Links, and Sitemaps
Redirects, canonical annotations, internal links, and XML sitemaps should point toward the same preferred URL. Conflicting signals make the migration harder to interpret. Google describes redirects andrel="canonical" annotations as strong canonicalization signals, while sitemap inclusion is weaker. Its canonicalization documentation recommends linking internally to canonical URLs and using self-referencing canonicals on canonical pages.
Preserve Page Purpose, Not Just Page Elements
A migration can keep the old title, H1, and URL yet still lose the page’s value. Designers may shorten the explanation that satisfied the query, move proof behind a tab that does not render as expected, remove internal links, replace a useful comparison with decorative graphics, or weaken the call to action. Create a one-page preservation brief for every critical template and landing page:- Audience and task: Who arrives here, and what must they understand or do?
- Intent ownership: Which question or decision belongs to this page rather than another URL?
- Essential information: Which explanations, specifications, evidence, policies, examples, or FAQs must survive?
- Trust elements: Which real author, reviewer, organization, contact, policy, case evidence, or source supports the page?
- Internal relationships: Which pages must link to and from this page?
- Search presentation: Which title, description, image, structured data, and visible headings need review?
- Conversion path: Which call to action, form, phone link, scheduling flow, or checkout step must work?
Do Not Copy Weaknesses for the Sake of “Parity”
Preservation does not mean freezing every old page. Fix inaccurate information, duplicate intent, inaccessible interactions, broken links, weak calls to action, and unsupported markup. The key is to label each substantive change, explain why it is needed, and measure the affected page group separately. That maintains accountability without carrying known problems into the new site.Worked Example: Redesigning a Service Site Without Losing Page Ownership
This is an illustrative example, not a Best Edge Tech client case study or a claim of results. Assume a 140-URL professional-services website is moving to a new WordPress build. The brand and domain remain the same, but navigation, service-page templates, forms, and 28 URLs are changing. The site earns qualified leads from organic search, and the team wants to combine several overlapping service pages.Step 1: Score the Risk
The project receives 2 points for URL changes, 2 for major content consolidation, 2 for a new build and hosting configuration, 2 for changed architecture, 2 for meaningful lead dependence, and 1 because a backup exists but rollback has not been rehearsed. The total is 11: high risk. That score changes the plan. The team adds a formal launch gate, rehearses recovery, and separates a planned domain change into a later project.Step 2: Record URL Decisions and Acceptance Evidence
| Old page | Decision | Reason | Required proof before launch |
|---|---|---|---|
| Main commercial service page | Keep | It owns a distinct service intent and already supports qualified inquiries | Same URL; preserved core answer, proof, internal links, canonical, form, and analytics event |
| Two overlapping subservice pages | Merge | Both answer the same decision and neither needs independent ownership | One stronger destination; unique useful material retained; both old URLs redirect directly to it |
| Outdated event announcement | Retire | No continuing demand, links, compliance need, or relevant replacement | Internal links and sitemap entry removed; intentional 404 or 410 response verified |
| Contact page | Keep | Low search traffic but essential to every conversion path | Form delivery, phone link, consent, confirmation, attribution, and error state tested |
Step 3: Define Page-Purpose Parity
For the main service page, “parity” does not mean matching the old word count. The acceptance record requires the new page to answer who the service is for, the problem it solves, the process, suitability and limits, differentiators supported by real evidence, service area where accurate, and the next step. It also records the queries and internal links the page owns. If the new design removes one of those functions, the issue is visible before launch instead of being discovered through a traffic decline.Step 4: Test the Rules as Data
The team exports every approved old-to-new mapping and tests it automatically, then manually reviews all critical pages and a sample from each redirect pattern. A passing row must return the intended status, land on the exact approved destination, avoid a chain, and end on a page whose canonical is itself. The production crawl must also find no staging hostname in canonicals, links, hreflang, structured data, or sitemap files.Step 5: Make the Launch Decision
One day before launch, three ordinary image URLs still return errors, but all critical controls pass. The image defects have owners and do not block a core task, so the launch authority can accept that documented exception. If the service-page form were failing, a critical redirect were unmapped, or production inheritednoindex, the same authority would stop the launch. The difference is not the number of open tickets; it is whether a defined stop condition has failed.
This example turns the checklist into a decision record: risk determines control depth, every important URL has an owner and rationale, each critical page has testable acceptance criteria, and exceptions cannot hide inside a generic “QA complete” status.
Run Production-Like SEO and Conversion QA on Staging
Staging is where the team should discover defects—not where it merely approves screenshots. Test representative pages from every template, plus every critical URL and user journey.Crawl and Index Controls
- Confirm staging is protected from public indexing using an appropriate access or indexing control.
- Prepare a documented launch step that removes staging-only blocks from production.
- Verify production robots rules, meta robots directives, canonicals, status codes, and hreflang where applicable.
- Confirm each production sitemap contains the canonical, indexable URLs intended for search. Google notes that submitting a sitemap is a hint, not an indexing guarantee, in its sitemap documentation.
Rendered Content and Template Parity
- Compare titles, descriptions, H1s, primary copy, internal links, image alternatives, canonicals, and structured data.
- Check content that depends on JavaScript, accordions, filters, faceted navigation, infinite scroll, or client-side routing.
- Validate that important links use crawlable anchors and point directly to final canonical URLs.
- Check that structured data describes visible page content and remains eligible for the intended feature; markup is not a guarantee of a rich result.
Performance, Accessibility, and Real Tasks
Measure representative templates and high-value pages rather than testing only the homepage. Google recommends good Core Web Vitals but also states that no single page-experience signal determines ranking; relevance remains central. Use its current Core Web Vitals guidance as a measurement reference, then collect real-user field data after launch. Test keyboard access, headings, focus order, labels, error messages, color contrast, zoom, and mobile behavior against the organization’s accessibility requirements. The Web Content Accessibility Guidelines 2.2 provide the authoritative technical standard. Accessibility should be a defined acceptance criterion, not a last-minute SEO item. Finally, complete the same tasks customers use:- submit every major form and verify delivery, confirmation, attribution, and error handling;
- test phone, email, booking, checkout, account, search, and download actions;
- verify consent behavior and analytics events under relevant user choices;
- test from representative devices, browsers, and network conditions;
- confirm thank-you pages and conversion events are not accidentally indexable when they should remain private.
Use a Launch Readiness Gate, Not a Hope-Based Deadline
A calendar date does not make a site ready. Define conditions that pause the launch until the issue is fixed or an accountable owner accepts the documented risk.Recommended Launch Stop Conditions
- A critical current URL has no approved keep, move, merge, or retire decision.
- A changed high-value URL has no tested relevant redirect.
- Production pages inherit a sitewide
noindexdirective or unintended robots block. - Canonical tags, hreflang, internal links, or sitemaps still reference staging or conflicting domains.
- Critical pages return the wrong status, render incomplete primary content, or are absent from navigation.
- Lead forms, booking, checkout, phone links, or analytics events fail their acceptance tests.
- The team lacks a current backup, recovery procedure, rollback authority, or incident contact.
- A major accessibility or security defect blocks a core user task.
Set Measurable Acceptance Thresholds
Thresholds should reflect the site’s size, technology, legal duties, and business risk. The following defaults are deliberately strict for critical controls and should be adjusted only through a documented exception:- 100% of known critical URLs have an approved disposition and pass their expected status or redirect test.
- 100% of critical conversion journeys complete successfully, including delivery and measurement—not merely the visible form submission.
- Zero production references to staging remain in canonical tags, hreflang, primary internal links, structured data, or XML sitemaps.
- Zero unintended index blockers appear on canonical pages selected for search.
- Zero redirect chains on critical URLs; noncritical exceptions require an owner and remediation date.
- Every representative template passes the agreed content, status, canonical, navigation, structured-data, accessibility, and mobile acceptance tests.
- Every open exception states its user impact, affected URLs, owner, deadline, workaround, and rollback implications.
Assign Ownership Before Launch
| Control | Primary owner | Required evidence |
|---|---|---|
| URL inventory and disposition | SEO and content | Approved mapping with page purpose and destination rationale |
| Redirect implementation | Development | Automated and manual test results against the approved map |
| Page and template parity | SEO, content, design, and accessibility | Representative-page QA with resolved defects |
| Analytics and conversions | Analytics and business owner | Completed test transactions or leads and verified reporting |
| Infrastructure and recovery | Development, DevOps, or hosting owner | Backup, capacity check, monitoring, rollback steps, and access |
| Go or no-go decision | Named project authority | Signed exception list or confirmation that stop conditions are cleared |
Prepare the First 48 Hours: A Migration Incident Playbook
Monitoring only helps when observations trigger decisions. Before launch, define who receives each alert, who can deploy a correction, and who can order a rollback. Use the timeline below as an operational starting point.| Window | Required checks | Escalate immediately when |
|---|---|---|
| 0–30 minutes | Uptime, DNS and HTTPS, homepage and critical templates, robots rules, index directives, top redirects, primary forms | The site is unavailable; production is blocked; a critical journey fails; or redirects create loops |
| 30 minutes–4 hours | Production crawl, mapping test, staging-reference scan, canonical and sitemap review, analytics events, server errors and capacity | A rule affects a page group, canonical signals conflict broadly, tracking is absent, or error rates threaten users or crawlers |
| 4–24 hours | Search Console inspection of priority URLs, paid and profile links, real lead delivery, logs, mobile tasks, representative structured data | Critical URLs cannot be crawled or rendered, conversions disappear, or old URLs lack their approved destinations |
| 24–48 hours | Page-group baselines, query and landing-page checks, index coverage signals, incident log, resolved-fix retests | A decline aligns with a technical defect, one template fails disproportionately, or an accepted exception has expanded |
Choose Fix, Roll Forward, or Roll Back
- Fix in place when the defect is isolated, understood, quickly testable, and does not leave users or crawlers exposed while the correction is prepared.
- Roll forward when the new release is structurally sound and a controlled patch is safer than restoring the old system.
- Roll back when a critical function is broadly broken, the cause is uncertain, remediation cannot be validated quickly, and the previous system can be safely restored.
Launch-Day Sequence
- Freeze uncontrolled changes. Record the final current-site crawl, configuration, content state, database backup, and approved release.
- Deploy the production build. Confirm the intended domain, HTTPS behavior, server capacity, DNS, certificates, cache rules, and environment variables.
- Remove staging-only restrictions. Check robots rules, meta robots, authentication, and any platform setting that discourages indexing.
- Activate and test redirects. Check critical URLs, samples from every rule pattern, files, images where relevant, and likely typo or slash variants.
- Verify canonical signals. New pages should point to their intended production canonical, and internal links should go directly to final URLs.
- Publish the production sitemap. Include canonical URLs intended for search and submit it through the verified Search Console property.
- Use the Change of Address tool only when appropriate. Google’s tool is for domain or subdomain moves, not ordinary path changes or HTTP-to-HTTPS moves.
- Run a production crawl and smoke test. Check status codes, index controls, metadata, structured data, templates, navigation, forms, and key device paths.
- Annotate the release. Record the exact launch time, changes shipped, known exceptions, and people on incident duty.
Monitor by Page Group, Query Group, and Business Outcome
Do not declare success because the homepage loads or total traffic looks normal. Compare the new site with the baseline at several levels.Immediately After Launch
- Confirm uptime, error responses, redirect behavior, crawl access, canonicals, sitemaps, forms, analytics, and server health.
- Inspect priority URLs in Search Console and review server or platform logs for unexpected crawler and user errors.
- Check paid campaigns, profiles, email templates, and high-volume referral links that may still point to retired destinations.
During Recrawling and Reindexing
- Compare old and new URL indexing, search clicks, impressions, queries, and landing pages.
- Segment results by template, folder, page intent, device, country, brand versus nonbrand demand, and conversion type.
- Track redirect errors, soft 404s, unexpected canonical choices, excluded pages, duplicate URLs, and newly orphaned pages.
- Compare conversion completion and quality, not just sessions or raw lead counts.
- Keep an incident log connecting symptoms to fixes and revalidation dates.
Post-Redesign Diagnosis Matrix
| Observed symptom | First checks | Likely owner |
|---|---|---|
| Most organic landing pages drop at once | Index directives, robots rules, server errors, domain and protocol configuration, tracking integrity | Development, infrastructure, SEO, analytics |
| Old URLs remain visible or return errors | Redirect coverage, status codes, destination relevance, chains, sitemap and internal links | Development and SEO |
| Only one template type declines | Rendered content, repeated metadata, canonical logic, structured data, internal links, pagination | Development, SEO, content |
| Brand search is stable but nonbrand demand falls | Intent coverage, page consolidation, headings, copy depth, internal linking, lost topic pages | SEO and content |
| Traffic is stable but leads or sales decline | Forms, calls, checkout, mobile usability, CTA visibility, consent, attribution, event tracking | UX, development, analytics, business owner |
| Reported traffic falls but Search Console clicks do not | Analytics tag deployment, consent mode, cross-domain tracking, filters, channel grouping | Analytics and development |
What a Generic Redesign Checklist Usually Misses
Many migration guides correctly mention crawling, redirects, sitemaps, and monitoring. Those are necessary, but they do not fully protect the business. A stronger process also includes:- Decision traceability: every URL and major content change has a reason, evidence, owner, and reversal path.
- Intent preservation: the team knows which user decision each critical page owns.
- Conversion verification: search traffic and real customer actions are tested as one system.
- Launch stop conditions: unresolved critical defects can pause the release.
- Template-level monitoring: problems are isolated faster than they would be with sitewide averages.
- Accessibility acceptance: core tasks remain available to users with different access needs.
- Incident ownership: the team knows who can diagnose, approve, deploy, and roll back a fix.
