Redesigning your website without losing your Google rankings

A business decides its website looks dated. A new design gets approved, a developer builds it, launch day goes well, and three weeks later the enquiry form is quiet. Nobody touched the marketing budget. What changed is that Google stopped sending people, because the pages it knew about disappeared and nothing told it where they went.

This is one of the most common and most avoidable problems in web work. A redesign, a move from WordPress to a custom Next.js site, a switch of domain or just a reorganised menu can all wipe out search traffic if they are handled as a pure design project. Handled as a migration, they usually keep rankings intact and often improve them. This post is the process I use.

Why redesigns lose traffic

Google ranks individual URLs, not your brand. When /services/kitchen-cleaning has been ranking for two years, that specific address carries the history: the links pointing at it, the clicks it earned, the content Google has judged useful. If the new site moves that page to /what-we-do/kitchens and the old address returns a 404, Google sees a page that vanished and a new page with no history. The new page has to earn its place from scratch, and it may never get back to where the old one was.

The usual causes are predictable:

• URLs change with no redirects. By far the biggest one.
• Content gets cut. A designer trims a 900-word service page down to three lines and an icon because it looks cleaner. The page that ranked for real questions now answers none of them.
• Titles and meta descriptions get reset. A new template ships with generic titles like "Home" or "Services".
• Pages get blocked by accident. The staging site's noindex tag or a restrictive robots.txt goes live with the launch.
• Internal links break. Old blog posts still link to addresses that no longer exist.
• The site gets slower. Heavy animations and uncompressed images push load times up, which hurts both rankings and conversions.

None of these are hard to prevent. They just need someone to own the SEO side of the project from the first week, not the day before launch.

Step 1: inventory every URL that matters

Before anyone designs anything, list what the current site actually has. You want every URL that gets traffic, has links pointing to it, or is in Google's index. Pull them from a few places:

• Google Search Console. The Pages report shows indexed URLs, and the Performance report shows which pages get clicks and for which queries. Export the last 12 to 16 months.
• The current sitemap. Usually /sitemap.xml or /sitemap_index.xml on WordPress.
• A crawl of the live site. A crawler like Screaming Frog follows every internal link and finds pages that are not in the sitemap.

Put everything in one spreadsheet with columns for the old URL, monthly clicks, the main queries it ranks for, and what should happen to it. This spreadsheet becomes the backbone of the whole project.

Step 2: decide the fate of each page

Every old URL gets one of three outcomes:

1. Keep the same URL. The best option when the page still exists in the new structure. If you can keep your URLs, keep them. A prettier URL is rarely worth the risk.
2. Redirect to the closest equivalent. When a page moves or merges into another, a permanent 301 redirect sends both users and Google to the new address and passes along most of the old page's signals.
3. Let it go. Thin, outdated or duplicate pages with no traffic and no links can return a 404 or 410. Not everything needs a redirect.

The mistake to avoid is redirecting everything to the home page. Google treats a pile of unrelated redirects to the home page much like a 404, and visitors who clicked a link about a specific service land somewhere that does not answer their question. Each redirect should point to the page that genuinely replaces the old one.

Step 3: build the redirect map

The redirect map is a two-column list: old path, new path. Where it lives depends on the stack:

• WordPress: a redirect plugin or server rules in .htaccess or Nginx.
• Next.js: the redirects() function in next.config.js, or middleware for large or pattern-based maps.
• Behind a reverse proxy like Caddy or Nginx: redirect rules at the server level, which work no matter what the application is.

A few rules keep the map clean:

• Use 301 (permanent) redirects, not 302s, for pages that have moved for good.
• Avoid chains. If /a redirected to /b years ago and /b now moves to /c, update /a to point straight to /c.
• Handle the variants. Trailing slashes, www versus no www, and http versus https should each resolve in one hop to the final URL.
• Keep the map in version control with the rest of the site, so it survives the next redesign too.

Step 4: keep the content that ranks

Design and SEO pull in different directions here. The new design will want less text. The pages that rank usually rank because they have the text.

Look at the queries each important page ranks for in Search Console. If the old kitchen-cleaning page ranks for "kitchen deep cleaning price" and "how long does kitchen cleaning take", the new page must still answer those. It can answer them better, with clearer layout, tighter writing and real photos, but the substance has to stay.

The same goes for the on-page basics. Carry over or improve each page's title tag, meta description, H1 and headings, image alt text and structured data. Write them deliberately for the new pages instead of accepting whatever the template generates.

Step 5: test everything on staging first

Build the new site on a staging environment, a private copy that is not public, and test the migration there before launch. If you do not have one, the staging environment guide covers how to set one up. On staging:

• Run the redirect map against the new site. A short script that requests every old URL and checks it returns a single 301 to the expected new URL, followed by a 200, catches most mistakes. On larger maps this is the only realistic way to check.
• Crawl the staging site for broken internal links, missing titles, duplicate titles and pages with no H1.
• Check speed on the heaviest pages. A redesign is a good moment to fix slow images and scripts, and a bad moment to add new ones. The Core Web Vitals guide explains what to measure.
• Keep staging out of Google with password protection or a noindex header, and write down exactly where that protection lives so it can be removed at launch.

Step 6: launch day checklist

Launch early in the week, not on a Friday, so problems surface while people are around to fix them. Right after the switch:

• Confirm the noindex tag, header or password from staging is gone on production.
• Check robots.txt allows crawling and points to the sitemap.
• Spot-check the top 20 old URLs from your spreadsheet in a browser and with curl -I to see the redirect status.
• Submit the new sitemap in Google Search Console.
• Use the URL Inspection tool on the most important new pages and request indexing.
• If the domain itself changed, keep the old domain registered and redirecting, and use the Change of Address tool in Search Console.
• Check that analytics and any conversion tracking still fire, especially form submissions.

Step 7: watch the first four to eight weeks

Some movement in rankings after a migration is normal while Google recrawls and reprocesses the site. What you are watching for is a drop that does not recover. Each week, look at:

• Search Console's Pages report for new "Not found (404)" errors. Every one that used to get traffic needs a redirect.
• Performance by page, comparing the new URLs against what the old URLs earned before launch.
• Server logs or error monitoring for 404s hit by real visitors and bots, which often reveal old URLs that never made it into the inventory.
• Enquiries and conversions. Rankings matter only because they bring customers. If traffic holds and enquiries drop, the problem is the new design, not SEO.

Platform moves: WordPress to Next.js and back

A lot of redesigns are also platform changes. A business on an aging WordPress build wants something faster and easier to maintain, or a custom site gets replaced by WordPress with Elementor so the team can edit pages themselves. I covered how to choose between them in WordPress with Elementor or a custom Next.js site.

Either direction works for SEO, as long as the migration steps above are followed. A few platform-specific traps are worth knowing:

• WordPress creates URLs you did not ask for: tag archives, author pages, attachment pages, date archives and ?p=123 style links. Decide which of these have any value before you move, and redirect or drop the rest.
• A custom Next.js site does nothing for SEO by default. Titles, meta descriptions, canonical tags, the sitemap, structured data and Open Graph tags all have to be built in. Make sure they are on the task list, not assumed.
• Blog posts are often the bulk of the traffic. Migrating 200 posts is a content project in its own right, including images, internal links and the URL pattern for each post.

For WordPress sites like Alpha Green and AgriDev, building with Elementor means the team edits content without a developer, which matters long after launch, because the content is what keeps ranking. For custom builds, the SEO plumbing becomes part of the code and gets the same review as any other feature.

Three questions to ask first

If you are planning a redesign or a platform move, ask whoever is building it three questions before work starts. Do you have a list of our current URLs and their traffic? How will old URLs redirect? Who checks Search Console after launch? If the answers are vague, the migration is not planned yet.

Need a hand with a redesign?

I design and build websites on both WordPress and Next.js, and I handle the migration side: URL inventory, redirect maps, staging checks, launch and monitoring. You can see recent builds on the work page, read more about how I work, and if a redesign or platform move is on your list, get in touch by email at hello@eliechaaban.com or book a call.