Redesign without losing your Google rankings.

A website redesign can make a site faster, cleaner and more effective. But it can also wipe out, within a few weeks, Google rankings that took years to build, if the old addresses stop working or the new site goes live hidden from search engines. The difference rarely lies in the design. It lies in a few technical checks before and after launch.

The steps that follow are based on Google’s guidelines and on what we’re doing right now on our own site: the old English weblab.gr, with Yoast SEO, is being replaced by a new Greek site with a different address structure. They apply to any WordPress site that changes theme, structure or language.

01Before the website redesign: list your URLs

The first step happens before the first page is designed: a complete list of the current site’s addresses. Anything left off this list risks ending up on a 404 page after launch. Google suggests combining several sources, because none of them has everything:

• XML sitemap. If the site has Yoast SEO, the index is at /sitemap_index.xml. That’s where we started too, for the old weblab.gr.
• Search Console. In the “Performance” report, export the pages with clicks and impressions from the last few months: these are already bringing people in.
• Analytics. The landing pages with the most traffic, from all sources and not just search.
• Backlinks. The Search Console “Links” report shows which of your pages have links from other sites.
• Crawl. A tool like Screaming Frog finds pages that aren’t in any sitemap, PDF files, images and old addresses with parameters.

Along with each URL, keep the SEO title, the description (meta description), the H1 heading and, if you can, the searches it appears for. You’ll need the same file for the post-launch check too.

02URL map and one-to-one 301 redirects

With the list ready, you build the map: for each old URL, what the new one is. Google’s site move guidelines ask you to map every old URL to its new address. On our own site, for example, the old English pages have a different structure from the new ones:

The rules that make the difference:

• Permanent redirects, from the server. Use 301 (or 308). According to Google’s guidance on redirects, a permanent redirect signals that the new address should appear in search results, while with a temporary 302 or 307 the old one may stay. 301s don’t cause a loss of PageRank.
• No chains. Every old URL goes straight to the final destination. If the site already has redirects from a previous change, update those too, so there aren’t two or three hops.
• Never everything to the home page. The most common “solution” is to send all old URLs to the home page. Google warns that this confuses visitors and may be treated as a soft 404, i.e. as if the page doesn’t exist.
• 404 or 410 where there’s no equivalent. If a page isn’t being carried over, it’s right for it to return 404 or 410. If several old pages are being merged into one new one, they can all point to it.

In WordPress, redirects go either in the server configuration (.htaccess or Nginx) or in a plugin. Whichever you choose, test them before launch: with a script or crawler for the whole list, and with Search Console’s URL Inspection for the important pages.

03Keep what already works on your pages

Redirects carry over the addresses, not the reasons a page ranks. If the page that brought traffic for “e-shop development Corfu” is rewritten as three lines under a big slider, Google will see a different page and assess it from scratch.

For the pages that bring clicks, keep the topic, the main sections of the text, the SEO title, the description and the structured data (schema), unless you have a specific reason to change them. If the language changes too, as on our own site, the page is essentially rewritten and you should expect bigger fluctuations. That’s why it’s best not to change more at once than you need to.

Measure speed before and after as well: a new theme with a heavy image at the top may have worse Core Web Vitals than the old one.

04Staging, noindex and launch day

The new site is built on staging, a copy at another address that must not appear on Google. In WordPress this is usually done with the “Discourage search engines from indexing this site” option (Settings → Reading), which adds the meta robots noindex, nofollow tag to pages. The WordPress documentation notes that it’s up to search engines to honor it, so a password on the staging site is safer.

The classic mistake: the site is moved from staging to the real address together with the database, and therefore with this setting still on. The new site works normally for visitors, but tells Google not to index it. Google says so explicitly: after the move, remove every noindex and every robots.txt block that was only needed for the migration. And if the staging site has already appeared on Google, don’t close it off with robots.txt alone, because then Google can’t read the noindex.

On launch day, in this order:

1. Turn off the search engine discouragement and check the code of the home page and a few inner pages.
2. Open /robots.txt and make sure it doesn’t contain Disallow: / or other blocks you don’t want.
3. Turn on the redirects and test the whole list of old URLs.
4. Search the database and the code for the staging domain. It’s often left behind in links, images and canonicals.

05Canonical, hreflang and internal links

Every new page needs a self-referencing canonical, with an absolute address (https://…) rather than a relative one. Yoast and most SEO plugins do this automatically, but after a migration it’s worth checking that it points to the real domain and not to staging or the old URL.

Internal links (menu, footer, links within the text) should point straight to the new URLs. Redirects would work, but every link to an old address is an unnecessary hop and a contradictory signal about which page is the canonical one.

If the language changes or languages are added, you need hreflang, which tells Google which page is the translation of which. The rules are strict: each version references itself and all the others, otherwise the tags are ignored; language codes follow ISO 639-1 (el, en); and x-default sets the page for visitors who don’t match any language. Multilingual plugins can generate them, but check them in the code.

On our own site, as long as there’s only the Greek version, hreflang isn’t needed. When English is added, the redirects of the old English pages must point straight to the new English pages, with no intermediate step. This is part of technical and multilingual SEO and is worth planning from the start.

06Sitemap and Search Console after launch

As soon as the site goes live, submit the new XML sitemap in Search Console. Google suggests temporarily keeping a sitemap with the old URLs too, so you can see them drop out of the index. Redirect warnings in that sitemap are expected. In WordPress the old sitemap no longer exists, so you upload it as a static file with the list from the first step and remove it once the old pages have left the index.

The Change of Address tool is only needed when the domain or subdomain changes, e.g. from example.gr to example.com. It isn’t needed for a change from http to https, from www to non-www, or for a new URL structure on the same domain, as in our redesign. It requires a 301 from the old home page to the new one and ownership of both properties with the same Google account, and it applies for 180 days.

07The weeks after: what to monitor

A launch without mistakes doesn’t mean traffic stays the same from day one. Google writes that rankings will fluctuate temporarily and that for a medium-sized site it can take a few weeks or more until the new URLs appear in place of the old ones. A mild, temporary drop is to be expected.

For the first few weeks, every week:

• Page indexing. The Search Console page indexing report shows the 404s, the pages with noindex and the soft 404s. 404s aren’t always a problem, if the page was removed on purpose. Fix those that come from your own links or the sitemap, and those that correspond to pages that were moved and should have had a redirect.
• Performance. Compare clicks and impressions per page with the file from the first step.
• Logs and 404 tracking. Visitors find old links that no tool had picked up. Each such URL gets its own redirect.
• External links. For the most important ones, ask the sites to update the address. Google suggests this too.

If you’re preparing a redesign, a technical audit of your current site provides the basis for the list. And when you ask for a quote for a new website, ask for it to include the migration too: URL map, redirects and a post-launch check.

08FAQ

How long should the redirects stay in place?

Google recommends at least a year, and as long as possible. We leave them in place permanently, because old links on other sites, in emails and in posts are still out there.

What if only the design changes and not the URLs?

Then you don’t need redirects or a Change of Address. The rest of the list still applies, starting with the staging noindex.

When should I worry about a drop in traffic?

If after a few weeks some pages haven’t recovered while the rest have, check their redirect, noindex, canonical and content. A general drop from day one usually points to a noindex or a robots.txt block.