The Website Redesign SEO Checklist (Including WordPress to Astro Migrations)
A redesign is the most common way a business loses rankings it spent years earning, and the loss is almost always avoidable. This checklist follows Google's own site-move guidance step by step, then adds the WordPress-specific traps — the image URLs, archives, and plugin pages that vanish when you change platforms — that generic checklists leave out.
Every month someone contacts us with the same story. The new website launched, it looks much better, and three weeks later the phone stopped ringing. Search Console shows a cliff. The old agency says rankings “always dip after a redesign.” They don’t, or at least they don’t have to. What happened is that URLs the old site had earned rankings for stopped existing, and nothing told Google where they went.
This checklist is the process we run on every migration, and it follows Google’s own site-move documentation. It is long because the work is real. It is also the difference between a redesign that improves your visibility and one that quietly deletes it.
What a safe redesign migration looks like
- Crawl the old site Every URL, title, and ranking page recorded
- Map old to new One-to-one redirects, no catch-alls
- Ship 301 redirects Served at the edge, tested before launch
- Set canonicals One address per page, no duplicates
- Submit the sitemap Only live, indexable URLs
- Watch indexing Search Console for 4–8 weeks
Before anything changes: record the old site
You cannot protect what you haven’t measured. Everything else depends on this step.
- Crawl the entire old site with a crawler (Screaming Frog, Sitebulb, or any equivalent) and export every URL, its title, its status code, and where it is linked from. Include images and PDFs.
- Export Search Console data: every page with impressions and clicks over the last 12 months, and the queries behind them. This tells you which URLs are actually earning anything. It is often not the pages you’d expect — an old blog post or a specific service page can carry a surprising share.
- Export analytics landing pages for the same period, so paid and referral traffic destinations are captured too.
- List every external link you know of pointing at specific pages — directories, partner sites, press. Those links are value that dies if the destination 404s.
- Record current Core Web Vitals and speed for key pages, so you can prove the new site improved them.
- Note every redirect the old site already has. Old redirects that get dropped become new 404s.
Plan the URL map
- Decide the URL structure of the new site before designing it. Structure is an SEO decision, not a design afterthought.
- Keep slugs identical wherever you can.
/services/water-heater-installation/on the old site should be/services/water-heater-installation/on the new one. Every unchanged URL is a page that needs no redirect and loses nothing. When we migrate WordPress sites to Astro, this is the first rule: preserve the permalinks. - Build a one-to-one map for every URL that changes: old URL → the single most relevant new URL. Not the homepage. Redirecting many old pages to the homepage is treated by Google as a soft 404, and the old pages’ value is lost anyway.
- Decide, explicitly, what will not exist on the new site — thin pages, old campaign pages, duplicate archives — and where each one redirects. “Nowhere” is a decision, not an oversight; if a page had no traffic and no links, a clean 404 or 410 is acceptable. If it had either, redirect it.
- Consolidate deliberately. Three old pages about the same service can redirect to one strong new page. That is a legitimate improvement, as long as the new page genuinely covers what all three did.
The WordPress-specific traps
Generic checklists treat platform changes as a footnote. On a WordPress site, the platform generates hundreds of URLs you never consciously created, and several of them will be earning traffic or carrying links. When the new site isn’t WordPress, all of them vanish unless you plan for them.
| What WordPress generated | Where it lives | What to do on the new site |
|---|---|---|
| Uploaded images | /wp-content/uploads/2023/05/kitchen-remodel.jpg | Images are often linked from directories and ranking in image search. Map the ones with traffic or links; serve them at the same path or redirect to the new asset. |
| Query-string permalinks | /?p=123 | Old links and emails often use these. Redirect each to its post’s new URL. |
| Category and tag archives | /category/news/, /tag/roofing/ | Usually thin. Redirect each to the most relevant hub or service page; don’t leave them as 404s if they carried links. |
| Author and date archives | /author/admin/, /2022/03/ | Almost always worthless. Redirect to the blog index. |
| Feeds | /feed/, /category/news/feed/ | Provide a feed at the new site’s address and redirect the old one, or return 410 if you are dropping RSS. |
| Pagination | /blog/page/3/ | Redirect to the blog index or preserve if the new site paginates identically. |
| Plugin-generated pages | Event pages, portfolio items, landing-page plugin URLs, /wp-json/ | Crawl for them explicitly; they are the ones nobody remembers exist. |
| Attachment pages | /kitchen-remodel-2/ (an image’s own page) | Redirect to the parent post or the image itself. |
| Trailing-slash and case variants | /Services/ vs /services/ | Standardize on one form and redirect the rest. |
One more WordPress-specific point: plugins that injected schema, meta titles, and canonicals (Yoast, Rank Math, and the like) stop injecting them the moment you leave. Every one of those needs to be rebuilt deliberately in the new site’s templates, and audited, because plugin defaults drift over time and the old site may have been shipping mistakes you’ll want to fix rather than copy.
Build and test on staging
- Keep staging out of Google’s index — password protection is safest; a noindex tag or robots block is the common alternative. Then write down exactly what you did, because you will need to undo it at launch.
- Implement every redirect on staging and test them with a crawler: crawl the full old-URL list against the staging domain and confirm each returns a single 301 to the intended destination, with no chains and no loops.
- Confirm canonical tags on every page point to that page’s own final URL, using the production domain, not staging.
- Rebuild structured data — Organization, LocalBusiness or its subtype, Service, Article, BreadcrumbList — and validate it.
- Rebuild titles and meta descriptions, page by page. Don’t lose the ones that were working; improve the ones that weren’t.
- Check internal links. A new site with links still pointing at old URLs makes Google crawl through redirects on your own site. Update every internal link to the final URL.
- Check that content is real HTML. Service details locked in images, sliders, or JavaScript-rendered fragments may have been readable on the old site and not on the new one, or vice versa.
- Generate the new sitemap and confirm it contains only live, indexable, canonical URLs. No staging URLs, no redirects, no noindexed pages.
- Compare Core Web Vitals against the numbers you recorded. A migration to a lighter architecture should be faster; if it isn’t, find out why before launch.
Launch day
Google’s advice for site moves is to change only one thing at a time and to use server-side 301 or 308 redirects. Here is the launch-day sequence that follows it.
- Remove the staging noindex or robots block. Do this first, and check it on the live domain the hour you launch. This is the single most common post-launch disaster: a site that looks perfect and is invisible because one setting stayed on. It happens to professional agencies.
- Confirm redirects are live at the edge. On a Cloudflare-hosted site this means the redirect rules are deployed with the site, so old URLs resolve instantly without hitting a server. Re-run the old-URL crawl against the live domain.
- Submit the new sitemap in Search Console. If the domain changed, use the Change of Address tool as well.
- Check canonicals on the live domain — production URLs, not staging.
- Update the Google Business Profile link, directory listings, and social profiles if any URLs they pointed to changed.
- Test every form and tracking event. Not strictly SEO, but a redesign that breaks the enquiry form has lost more than a redesign that loses a ranking.
The four to eight weeks after
Google’s documentation says a small-to-medium site can take a few weeks for most pages to move, and that some changes take months. This is a waiting period, not a fault, but it is one you should watch.
- Search Console → Pages report, weekly. Watch for a rising count of “Not found (404)” or “Redirect error” entries; each one is a URL you missed. Fix them as they appear.
- Search Console → Performance, weekly, comparing the same weeks last year and the weeks before launch. Expect fluctuation. Investigate sustained drops on specific pages by checking their redirects and their content.
- Crawl the live site monthly for the first quarter, looking for internal links to old URLs, unexpected noindex tags, and broken redirects.
- Keep every redirect for at least a year (Google’s minimum) and realistically forever. On a modern edge platform they cost nothing.
- Do not make a second wave of large changes during this period. Let the first one settle so you can read the results.
The honest summary
Rankings are attached to URLs, not to designs. Preserve the URLs where you can, redirect them one-to-one where you can’t, keep staging settings out of production, and give Google the weeks it says it needs. A redesign done this way is one of the best things you can do for search visibility, because the new site is usually faster, deeper, and better structured than the one it replaced. A redesign done without it is how businesses lose years of work in a fortnight.
If you are deciding whether to redesign at all, Signs Your Website Needs a Redesign will help you decide without emotion. If you are choosing what to move to, WordPress vs Astro for Business Websites covers the trade-offs. And every CactusLaunch migration runs this checklist as part of the build — it is listed as a line item in the launch plan, because the packages that include migration price it as the real work it is.
Questions people ask
Will a redesign hurt my rankings?
A redesign done without a URL plan very often does. A redesign done with this checklist usually produces a short period of fluctuation while Google re-crawls, then recovers, and frequently improves because the new site is faster and better structured. The difference is entirely in the preparation, not the design.
Do I need redirects if the URLs aren't changing?
If every URL is genuinely identical, no redirects are needed for those pages, and that is the safest kind of migration. But check the details — trailing slashes, uppercase letters, .html extensions, www versus non-www, and WordPress query-string URLs all count as different URLs. Crawl both sites and compare before assuming.
How long should redirects stay in place?
Google's site-move documentation says at least one year. In practice, on a modern edge platform they cost nothing to keep, so leave them permanently. Removing them is a risk with no reward.
Can I change the platform, the design, and the URLs all at once?
You can, and it is the highest-risk version of a redesign. Google's guidance is to change one thing at a time. When a platform change is unavoidable, we keep URL slugs identical wherever possible so the platform changes and the addresses don't, which turns the riskiest migration into a much safer one.
How much traffic will I lose during the migration?
Nobody can honestly put a number on it in advance; it depends on how much of your traffic sits on pages that change and how well the redirects are done. What we can say is that a migration with a complete redirect map, unchanged slugs, and clean indexing signals typically shows a brief wobble rather than a collapse, and that the collapses we get called in to fix almost always trace back to a missing redirect map or a noindex tag left on.
This article is part of the seo & local search library. If it describes a problem you have, the service behind it is here: see seo services.
Keep reading
Why Isn't My Website Ranking on Google? A Four-Stage Diagnosis
Not ranking is a symptom with four very different causes. This guide walks a business owner through them in order — not indexed, indexed but invisible, ranking but missing from the map pack, ranking but producing no leads — with the exact Search Console reports that tell you which one you have.
Signs Your Website Needs a Redesign (and When It Doesn't)
"Every three to five years" is a rule of thumb, not a diagnosis. Here is a ten-point self-audit using free tools, a decision tree for fix versus restructure versus rebuild, and the honest cases where the right answer is to leave the site alone and repair three specific things.
WordPress vs Astro for Business Websites - An Honest Decision Guide
WordPress runs a huge share of the web and Astro is what we build on. Neither is "better" in general. Here is what each one is actually good at, the three questions that decide it for a service business, what happens to editing, forms, and blogs when you leave WordPress, and the cases where WordPress is still the right answer.