An SEO website redesign does not fail because of a bad checklist. It fails because nobody exported the old URL list before the new site went live. Google’s site-move documentation starts there: inventory your sitemaps, server logs, and analytics for your highest-traffic URLs, then pull Search Console’s “Links to your site” report before anyone touches a redirect. Most agency checklists skip straight to “add 301s.” That is step four, not step one.
A redesign proposal that only promises “an SEO audit” is promising a vibe, not a deliverable. If the audit does not produce a URL export, an asset list, and a redirect map before design starts, the SEO work has not started.
Inventory everything before you touch the build
Google’s guidance is specific about what counts as a URL worth protecting. Pull every important page from your sitemap, server logs, and analytics, ranked by traffic, and cross-reference it against Search Console’s inbound link report so pages with backlinks you did not know about do not get dropped. Then do the part most proposals skip: list embedded assets too. Images, PDFs, videos, and standalone CSS or JS files can already be ranking or already have inbound links, and Google treats them the same as HTML pages.
Verify every host variant in Search Console, www and non-www, HTTP and HTTPS, on both properties, since a lot of redesigns swap the analytics snippet and quietly break verification on day one. Re-check the settings a handoff loses too: crawl rate left on “let Google decide,” the disavow file re-uploaded, and, on a newly purchased domain, leftover manual actions from a previous owner.
HubSpot’s redesign checklist adds the business side: benchmark rankings, bounce rate, time on site, domain authority, form submissions, and sales before anything changes, and flag pages with the most shares, links, and ranking keywords so nobody “simplifies” them out of the new sitemap. A proposal that bundles this baseline into the price is doing diligence; one that promises “SEO-friendly redesign” with no numbers attached is selling a feeling.
If a full move feels risky, migrate a quieter section first and watch its traffic and indexing before moving the rest. A section test will not perfectly predict the full-site result, but it beats finding out everything at once on launch day.
Map every redirect correctly, not just “use 301s”
Most agency checklists get the headline right and the detail wrong. The common claim is “always use 301s, never 302s, because 302s leak ranking value.” Google has stated plainly that permanent redirects, 301 or 308, do not cause PageRank to be lost. The real distinction is canonical signaling: a permanent redirect tells Google the new URL should be the one shown in results, while a temporary redirect (302, 303, 307) tells Googlebot to follow without switching the canonical, so the old URL can keep showing up for a while. Pick the redirect type based on whether the move is permanent, not a PageRank-loss myth.
Chains hurt more than the redirect type. Googlebot follows up to ten hops, but Google recommends redirecting straight to the final destination; keep an unavoidable chain under five hops, ideally three, since every hop adds latency.
Keep redirects live for at least a year, Google’s own window for link equity to get recrawled against the new URL, and update your internal links to point straight at new URLs anyway. One thing people over-apply: Search Console’s Change of Address tool is only for a domain or subdomain change, not a path change or an HTTP-to-HTTPS switch.
This is where I would push back on a common proposal format: a redesign RFP that lists “301 redirect setup” as a single line item is underscoping the job. A Shopify rebuild I worked on had a URL map over a hundred paths once filtered collection pages and old blog tags got counted. That is a spreadsheet with its own review pass, not a line item.
Keep indexation clean through launch, not after
A redirect map gets a project most of the way to a safe website redesign, but indexation is the part that breaks quietly. If staging used robots.txt or noindex to hide the build from Google, produce the list of URLs that need noindex removed before launch and confirm the production robots.txt ships. Forgetting that is common enough that Google calls it out by name as a migration failure. Robots.txt controls crawling, not whether a URL shows up in results, so to actually exclude a page from search, noindex or password protection is the tool.
Every new URL needs a self-referencing canonical tag once redirects are live, and internal links should point directly at new URLs instead of routing through a redirect. Pages genuinely going away should return a real 404 or 410, not a soft 200 that confuses a crawler.
Sitemaps are not automatically required. Google says you probably do not need one under roughly 500 pages comprehensively linked from the homepage, and you do need one if the site is large, new, or heavy on video, image, or news content. Submit the new sitemap after the move and drop the old one. For a client-side JavaScript rebuild, Googlebot crawls, renders, then indexes in that order, so a robots.txt block stops the fetch and the JS behind it never renders, which is why server-side or pre-rendering stays the safer default.
About 20 to 30 percent of the redesign work we get called in on starts as a DIY site that outgrew itself: weak heading structure, no sitemap discipline, DIY sites that fail to index because nobody checked Search Console. A redesign is the moment to fix that, not carry it into a nicer template.
Watch the right numbers before and after launch
Expect fluctuation. Google is direct about this: ranking changes are normal while it recrawls and reindexes, and for a medium-sized site it can take a few weeks or more for new URLs to fully replace old ones in results. Larger sites take longer, and the move is not “done” until Googlebot has visited every old and new URL at least once.
Track both old and new URLs together. The healthy pattern is old-site indexed counts falling while new-site counts climb, visible in the Sitemaps report, paired with Index Coverage for crawl errors and Performance for clicks landing on new URLs. If traffic looks gone, check the obvious thing first: watching the wrong Search Console property, HTTP instead of HTTPS, is probably the single most common reason a site looks like it lost traffic when it did not.
Core Web Vitals matter too: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, measurable from the Core Web Vitals report. Warn your host ahead of launch, since Google crawls a freshly moved site harder than usual, and a host that falls over under that load gets its crawl rate throttled back.
If a drop shows up site-wide rather than scattered, Google’s debugging path is the Performance report filtered to Pages, compared against the equivalent prior period, sliced by query, country, and device.
What actually causes a rankings drop
Most agency pages frame a redesign as inherently risky, often backed by a percentage statistic with no named study attached. Google’s position is less dramatic: PageRank is not lost to a 301, fluctuation is expected, and durable drops trace back to a short list of failures, not to “redesigning” as a category. Leftover noindex tags from staging, redirects pointed at the wrong destination, a spike in Index Coverage errors, insufficient server capacity, and a stale sitemap cover most of it.
The opinion I would put a stake in: a redesign RFP that treats SEO as a checklist item rather than a QA discipline is what causes the drop, not the redesign itself. Teams that change one major thing at a time, with a real inventory and a tested redirect map in hand, do not see the losses the checklist blogs warn about. Teams that swap domain, CMS, and visual design in one weekend, with the redirect map built the night before launch, are the ones explaining a traffic chart six weeks later. The cost of doing the inventory right is a less exciting kickoff call. The cost of skipping it is that conversation anyway, later, with a client watching.
If you are scoping this work and want it treated as a discipline instead of a line item, that is the shape of website redesign services worth paying for, paired with SEO / AEO / GEO work that keeps watching Search Console after launch instead of calling the job done at ship. The same logic applies to a straight website redesign: design decisions and indexation decisions get made by the same team, on the same timeline, or they get made against each other.