Website Redesign SEO Checklist: Protect Your Rankings

Short answer: a redesign does not lose traffic by itself. Losses usually come from things that change quietly alongside the new look: URLs that move without a plan, pages that vanish, internal links that disappear, a noindex or robots block left over from staging, and a launch that nobody watches closely afterward. This guide walks through the inventory to build before you touch anything, how to map old URLs to new ones, which design choices carry hidden SEO cost, what to check on launch day, how to decide on a rollback, and how to monitor the first month.

It is written for sites that already have history: pages in the index, inbound links and measurable traffic. If you are launching a site from scratch, start with the new website launch SEO checklist instead. That guide covers robots, noindex, staging setups, heading structure and analytics from zero, and those basics are not repeated here. The difference is simple: a new site has nothing to lose, while a relaunch has an inheritance to protect.

The main reference is Google's documentation on site moves with URL changes (Opens in a new tab) and on changing your web hosting (Opens in a new tab). Real redesigns are usually a blend of both situations. Google's documented limits and recommendations can change, so check the current pages before you rely on any number below.

What Kind of Relaunch Is This?

Before any checklist, name what is really changing. "New design" can mean anything from a fresh theme to a new platform, a new URL scheme and a new domain, and each carries a different level of risk.

Match the project to its risk

One change at a time, if you can

Google's general advice for moves is to change one thing at a time. Its own example is moving domains first and changing the layout as a separate step. Relaunch projects tend to bundle everything: theme, platform, copy, URL scheme and sometimes the domain. When traffic then drops, nobody can say whether the cause was the template, missing pages, redirects or shortened copy. If splitting the project is not possible, keep a written change log and treat each change as its own hypothesis afterward.

Timing and scope

The same documentation suggests timing a move for a period of lower traffic, such as a seasonal or weekday dip. For large sites it also describes moving one section first, ideally a stable one that is not strongly affected by frequent or unpredictable events, and small or medium sites can move all URLs at once. Launching during a seasonal peak or a major campaign both raises the cost of a mistake and muddies the reading of what went wrong.

Pre-Launch Inventory: URLs, Content, Traffic, Links

A migration is only as good as your knowledge of the old site. Projects that skip the inventory tend to discover, weeks later, that a page nobody remembered was earning traffic or links.

Where old URLs hide

Google lists several places to find them: sitemaps and the Links report in Search Console, server logs and analytics for high-traffic URLs, your CMS's content listings, and embedded resources such as images, videos, JavaScript and CSS. No single source is complete. A sitemap only knows what was submitted, analytics only knows what was visited, and the CMS only knows what it manages. Combine them.

A working inventory sheet

Build one row per URL with these columns:

1. Old URL: exact address including parameters and trailing slash.
2. Status today: 200, redirect or error.
3. Template type: homepage, category, product, article, tool, static page.
4. Search performance: clicks and impressions in recent months.
5. Inbound links: whether other sites link to it.
6. Title, description, canonical and hreflang: current values.
7. Planned fate: keep, merge, or retire.
8. New URL: destination if kept or merged.

Sort pages by what they are worth

Split the sheet into three tiers. Pages that earn traffic or links must be preserved as closely as possible, ideally on the same URL with the same copy. Low-value but harmless pages can be merged. Duplicated, empty or obsolete pages can be retired. Google says to return 404 or 410 for deleted or merged content that has no replacement, which is more honest than forcing every retired URL toward some arbitrary destination.

Inbound links belong in the inventory too

A page that loses its address or lands on the wrong destination loses what its inbound links were worth. The list of linked pages becomes the priority column of your mapping table. For the details of choosing targets and keeping that value intact, see preserving backlink value during a site migration. Google also advises saving a list of sites that link to your old URLs so you can ask them to update the links after launch.

Capture a baseline now

You can only call a drop real if you recorded the before. Export query and page level clicks and impressions from Search Console, organic sessions and conversions from analytics, and positions for a short list of important queries. If your business is seasonal, save the same window from the previous year too. Without a baseline, the week-two conversation becomes a debate about impressions instead of a comparison.

Inventory readiness checklist

• Sitemaps, logs, analytics and CMS lists are merged into one sheet.
• Pages with traffic or links are flagged.
• Images, PDFs and other downloads are included.
• Every page slated for removal has a 404 or 410 decision.
• Baseline metrics are saved with dates.
• A project owner and a rollback decision-maker are named.

URL Mapping and the Redirect Plan

The mapping table is the single most important document in a relaunch. Every old address needs a destination, or a written decision that it is being retired.

Building the map

Google's guidance is to map each old URL to its new destination and to store the map in a database or as rewrite rules. For a plain domain change, a wildcard server-side redirect can be enough. When the URL structure changes, you generally need a row-by-row table. Start it in a spreadsheet, then convert it into server rules or a redirect module, and make sure it can be tested before launch.

Redirect type and chain length

Google recommends server-side permanent redirects such as 301 and 308, with client-side redirects only as a last resort. Googlebot can follow up to ten hops, but the recommendation is to redirect straight to the final URL. When that is impossible, keep chains ideally under three hops and always under five. Chains in relaunches usually come from stacked history: an old HTTP address goes to HTTPS, then to a renamed folder, then to the new template path. Fold earlier redirects into your map so each old address resolves in one step. If you already have chains or loops, redirect chains and loops: how to fix shows how to find and untangle them.

Does a permanent redirect cost PageRank?

The documentation states that 301 and other permanent redirects do not cause a loss in PageRank. That is a statement about the mechanism, not a promise about rankings. What happens to rankings still depends on whether the new page truly replaces the old one, and on Googlebot visiting every old and new URL at least once. The move happens per URL, and crawl speed depends on site size and server speed.

The homepage shortcut

The most common shortcut is pointing hundreds of retired URLs at the homepage. Google cautions that sending many old URLs to one irrelevant page can confuse users and may be treated as a soft 404. Use a plain rule: redirect only when the destination genuinely answers what the old page answered. Otherwise return 404 or 410.

Decision rule for each old page

1. Does it earn traffic or links and exist on the new site? Redirect 301 to its direct equivalent.
2. Was its content folded into another page? Redirect 301 to that page.
3. Is there no content and no genuinely related page? Return 404 or 410.
4. Still undecided? Keep it on the open list and decide before launch. Do not default to the homepage.

Canonicals, hreflang and internal links on the new site

Redirects alone are not enough. Google's guide says each new URL should carry a self-referencing canonical, hreflang annotations should be updated to the new URLs, and internal links should be changed to point at the new addresses. Updating internal links also removes an extra hop for every click. On bilingual sites, test that each language version still points at its counterpart; if only one language changed its addresses, the pairs can break.

How long redirects should stay

Keep them for at least one year, according to Google, so signals can transfer and links to old URLs can be recrawled. From the user's side they can stay forever. Because redirects add latency, update your own links and high-volume external links to the new address where possible.

Design Choices That Quietly Hurt SEO

Designers aim for a clean and fast interface, while search engines need to see what a page says and reach it. Usually the two goals agree. The decisions below are where they sometimes collide. This section collects common technical patterns seen in redesigns rather than step-by-step items from Google's move documents, so how much they matter depends on your site.

Trimming copy for a cleaner look

New designs often ask for less text. Category intros, long product descriptions and sub-headings are cut, and with them go the words that made the page findable. Protect the visible text, title, main heading and sub-headings of every traffic-earning page, and let only the presentation change. If you want shorter copy, test it separately from the launch so you can read the result.

Navigation that orphans pages

A simplified menu can strip internal links from deeper pages. If a subcategory used to be reachable from a mega menu and now is not, it may become an orphan with no links. Make sure each valuable page in your inventory still has at least one internal link in the new structure.

Tabs, accordions and lazy content

Hiding long text behind tabs is a design choice, but text that only loads after interaction, or never appears in the server response, may not be seen by crawlers. Confirm that main content is present in the initial HTML, using view-source or the URL Inspection tool in Search Console.

Client-side rendering

A new front-end framework can render titles, canonicals, robots directives and body text only after JavaScript runs. That may delay or weaken indexing. Safer is to serve critical SEO elements in the first HTML response. Compare raw HTML from a sample of templates between old and new.

Titles, headings and template logic

When the template changes, so does the logic behind titles. Check that every page has a unique title element and a meaningful main heading, and that the same title is not repeated across hundreds of pages. Heading tags chosen purely for font size break the outline; keep style and meaning separate.

Heavy images, sliders and video backgrounds

Large hero media can slow pages. If image URLs change, traffic from image search and from sites embedding your images can vanish. Put image files in the mapping table, keep alt text, and measure speed before and after with the same tool.

Mobile parity

If the mobile layout carries less content or fewer links than desktop, you can lose visibility, since crawling is mobile-first. Compare hidden sections and removed links.

Design risk quick reference

Launch Day Checks and Rollback Plan

Launch day tests your preparation. A written sequence prevents guesswork and keeps decisions calm.

Remove staging protections first

Google's documentation says that if you blocked crawling or used noindex during development, you should prepare the production versions and a list of URLs to unblock. The hosting-change page repeats the point: remove robots.txt blocks and noindex from the new copy before the move begins. Put both at the top of your launch checklist.

Launch-day checklist

1. Production robots.txt is live: no important paths blocked, sitemap declared.
2. No noindex on important pages, in either meta tags or HTTP headers.
3. Each key page has a self-referencing canonical.
4. Sample old URLs from the map resolve in one hop to the right page.
5. Redirects return 301 or 308, with no chains or loops.
6. New pages return 200; retired pages return 404 or 410.
7. The new sitemap is submitted in Search Console and the old one removed.
8. Search Console and analytics verification work on the new site.
9. URL Inspection shows key pages as reachable by Googlebot.
10. Firewalls and DoS protection do not block Googlebot.
11. The server can handle the extra crawling that follows a move.

Testing the redirects at scale

Google suggests the URL Inspection tool for individual URLs and command-line tools or scripts for large sets. Running every row of the map automatically, then comparing the final status code and final URL to the expected values, is more reliable than clicking through a handful. Pay attention to rows whose destination does not exist on the new site, which Google lists among common mistakes.

When the Change of Address tool applies

Only for moving to a different domain or subdomain. It is not used for HTTP to HTTPS, www to non-www, or path changes. For a domain move, submit it for all verified variants of the old domain. A redesign that keeps the domain skips this step.

If hosting also changes

The hosting-move guidance adds more steps: lower the DNS record TTL to a conservative value of a few hours at least a week before the move, verify Googlebot access with URL Inspection, ensure firewalls do not block it, and shut down the old host only after its traffic reaches zero in the server logs. Add these to the list if your relaunch includes new infrastructure.

Write the rollback decision before launch

A rollback plan has three parts. First, the triggers: for example widespread 5xx errors on key templates, a crawl block that cannot be fixed quickly, or a large share of redirects pointing at wrong pages. Second, the mechanism: keep the old site runnable, know how to revert DNS, and know how to remove redirect rules. Third, the person with authority to pull the trigger. Targeted fixes usually beat a full rollback when only a few templates are affected.

Example scenario: a few hours after launch, someone notices that all category pages ship a noindex tag from the new template. That does not call for a rollback. The template gets corrected, the affected URLs are re-inspected and the sitemap is refreshed. If instead most mapped redirects send people to the wrong pages, bulk-fixing the rules or reverting becomes the right conversation. Deciding which situation maps to which response in advance saves hours.

First 30 Days: Monitoring and Fixes

The first weeks are the window in which problems are still cheap to repair. Monitoring should use several sources because each one answers a different question.

What each report tells you

Google's move documentation lists these same monitoring sources and notes that redirect warnings on the old sitemap are normal.

Week one: short daily review

Each day, ask a few questions. Do important pages return 200? Do sampled redirects still resolve correctly? Do the logs show a pile-up of errors? Has Search Console flagged a new crawl issue? The hosting-move page says to expect a temporary drop in Googlebot's crawl rate after launch, followed by a steady increase over the next few days, possibly above earlier levels, so a wobble in early crawl statistics is not alarming by itself.

Weeks two and three: compare to the baseline

Compare index coverage and query data to your saved baseline, group by group rather than only in total. Did new URLs fail to enter the index, or did they enter and rank differently? The first points to crawling, canonical or robots problems. The second points to content and internal-link differences.

Week four: mop up

Close leftover 404s, unexpected chains and any old URLs missing from the map. Replace internal links that still point at old addresses. Ask valuable external sites that link to old addresses to update them.

If traffic falls, work in this order

Start with technical health: crawlability, noindex, canonicals, redirect accuracy. Then isolate which page groups and queries account for the drop. Then compare old and new versions of those pages for copy, title and internal-link changes. To separate the effect of a relaunch from an overlapping Google update, follow the steps in diagnosing traffic loss after a Google update. When a relaunch and an update coincide, a single cause is often impossible to name, which is why the baseline and the change log matter.

Temporary wobble versus lasting loss

Google says ranking fluctuations are expected during a move and that medium sites can take a few weeks or more for new URLs to replace old ones, with larger sites taking longer. A dip in week one is not failure on its own. Pages that never enter the index, errors that stay unfixed, or key page groups that fail to recover over several weeks do signal a real problem. Waiting is not a diagnosis; once recovery stalls, start investigating.

Common mistakes recap

• Staging noindex or robots blocks left in production. If there is no robots.txt at all, it should return a proper 404.
• Redirects that point to URLs that do not exist on the new site.
• Crawl errors climbing unnoticed during the move.
• A server that cannot absorb the additional Googlebot load.
• Outdated sitemaps still listing old URLs.
• No analytics on the new site, which removes the comparison.

Google's migration guide names the same items among the mistakes to avoid.

Frequently Asked Questions

Will a redesign always cost me organic traffic?

No, but expect some turbulence. Google says that after a move with URL changes, a medium-sized site may need a few weeks or more before new URLs replace the old ones, and larger sites take longer. If URLs stay the same, content and internal links survive, and launch-day errors are caught quickly, the risk shrinks considerably. No step guarantees a particular outcome.

Do I have to change my URLs during a redesign?

No. Often the safest route is to keep every page address and change only the design and templates. If URLs must change, every old address needs a documented destination and a server-side permanent redirect. Changing the URL structure purely for tidiness adds risk without a measurable benefit.

How long should I keep the redirects in place?

Google recommends keeping redirects for at least one year so signals can transfer and links to old URLs can be recrawled. The same page notes that from a user's perspective they can stay indefinitely. Google's documented guidance can change, so check the current page before you act.

Is it acceptable to redirect every retired page to the homepage?

It is not. Google warns that sending many old URLs to one unrelated page, such as the new homepage, can confuse users and may be treated as a soft 404. Merging several old pages into a single new page that truly covers their topic is fine. For pages with no counterpart, return 404 or 410.

Should I use the Change of Address tool for every relaunch?

No. Google says to use it only for domain or subdomain changes. It is not meant for an HTTP to HTTPS switch, a www to non-www change, or path changes within the same domain. If your domain stays the same, the tool has no role.

Is this checklist the same as the new website launch checklist?

Only partly. A brand-new site has no history, no old URLs and no inbound links to protect. A relaunch inherits all of those, so inventory, mapping, rollback planning and loss diagnosis matter more. The shared basics are covered in the new website launch checklist.

Related guides: Maintenance Mode and SEO: Using 503 and Retry-After Safely, Staging Site Indexed by Google: How to Fix and Prevent It, Changing Web Hosts Without Losing Rankings: DNS Checklist, WordPress Tag and Archive Pages: Noindex or Index?.

Conclusion

Protecting traffic in a redesign comes down to three questions. Do you know exactly what the old site contains? Does every old address have an owner on the new site? Can you measure what happens afterward? Inventory and a baseline answer the first, the mapping table and clean redirects answer the second, and the launch-day list plus a 30-day review answer the third. Keep URLs unchanged where you can, avoid stacking big changes, write the rollback decision in advance and keep a change log. No measure guarantees a ranking outcome; the goal is to be able to find and fix any loss quickly.

If you want to strengthen the link profile of your most valuable pages during a relaunch, you can look at the backlink packages offered by Akua Adforce; scope and terms are described on the product page.