Website redesign SEO comes down to where every old address goes

You are about to redesign your website, and at the back of your mind is a number. It is how many enquiries arrive because someone searched for what you do and found you. You have heard of sites that relaunched looking better and then went quiet for months. The fear is fair. Most of what gets sold as website redesign SEO comes down to one plain question: when the new site goes live, where does every old address go?

Google has spent months or years learning which of your pages answer which searches, and it keeps what it learnt against addresses, the URLs in your browser bar. Change those addresses without telling Google where each one went, and the new site can be better in every way and still lose the leads. This is the website redesign checklist I work from, and my own relaunch proved I needed it.

Google still listed three addresses my own relaunch left answering 404

On 9 October 2026 I released the rebuilt bespokeforgestudio.com. The full story is in I rebuilt my own studio’s website. The rebuild changed a lot of addresses:

• Ten older guides on “fractional” engineering said overlapping things, so I merged them into three. WordPress keeps each old address on the guide that absorbed it, and forwards visitors there.
• I merged seventeen service pages into fourteen. Each absorbed page forwards to the page that took it in.
• I retired some of WordPress’s automatic lists on purpose: the engagement archives and the lists of posts by date. Nothing replaced them, so they answer 404, the code a server sends for “not found”. The old client archives were different. Their clients moved to the case studies, so those addresses forward there.
• I rewrote titles and descriptions where an audit found them missing or badly written, and the SEO plugin produced a fresh sitemap for launch.

A sample of the map, as the live site answers today:

Old address	New home	What it answers
/what-is-fractional-engineering/	/signs-you-have-outgrown-your-web-vendor/	301
/fractional-engineer-vs-agency/	/who-owns-your-systems-after-launch/	301
/services/reporting-dashboards/	/services/pipelines-and-reporting/	301
/services/crm-automations/	/services/crm/	301
/blog/	/guides/	301
A list of posts by month, such as /2026/06/	None, on purpose	404

After launch I went through the site in Google Search Console, Google’s free report on how your site appears in its results. Google still listed three old guide addresses, and all three answered 404. One of them was still collecting impressions, the times it was shown in results. Its average position was 7.8, so it usually sat on the first page, for a search somebody was making. Anyone who clicked it reached a dead end. Google removes an address that answers 404 from its index, so the place that page had earned was on its way out.

A forward you never planned is a forward that does not exist. That is why the list comes first.

A website relaunch checklist starts with the addresses you already have

Before anyone designs a page, find out what the current site owns.

• Crawl the live site. A crawler is a program that follows every link on your site and records each address it finds and the code it answers with. Search engines crawl this way, and a desktop crawler does it for you in minutes. Save the result. It is the list of addresses your site has today.
• Export the Search Console pages and queries. In the Performance report, set the date to the last 16 months, export the Pages tab, then the Queries tab. A crawl only finds pages your site still links to. Search Console also shows the addresses Google remembers, and that is where my three showed up. If you use Bing Webmaster Tools, export its pages too.
• Add the pages other sites link to. Search Console’s Links report lists your most-linked pages. A link from another site keeps sending visitors long after it was written, so the address it points at needs a home too.
• Map every old address to its new home. One row per address: the old address, the new one, and what it should answer. The new home is the page that answers the same question. It is not the homepage. Google’s guide to site moves says plainly not to redirect many old addresses to one irrelevant page such as the homepage. Google may treat such a forward as a soft 404, a page that loads but counts as missing.
• Decide on purpose which addresses end. Some pages have no successor and earned nothing. Let them answer 404, but check your export first, so nothing you retire is a page that ranks.

A move to a new domain needs a longer website migration checklist, and the same Google guide covers it.

During the build, every forward is permanent and every page that ranks keeps its words

Whether you can redesign a website without losing SEO is mostly decided here, in work no visitor ever sees.

• Forward each old address with a 301. A 301 is the answer a server gives for “this page has moved for good, and here is its new address”. Google reads a permanent redirect as a signal that the new address should be canonical. Canonical means the main address Google keeps for that page and shows in its results. A temporary redirect, a 302, does not carry that signal. Use a 302 only for a page that will return. One article I took offline for a while forwards to my guides with a 302 for exactly that reason.
• Point each forward straight at its final page. Google’s crawlers follow up to ten forwards in a row, but every extra step is another place to break. Old address to new home, in one step.
• Keep the titles and headings that rank. The title is the headline Google shows for your page in its results. A title and a heading that already match what people search for are worth keeping, unless you have a reason to change them. On my site the reason was an audit. Where it found titles and descriptions missing or badly written, I wrote new ones.
• Carry over the structured data. Structured data is code in the page, invisible to visitors, that tells search engines what the page is: a service, an article, a set of questions and answers. If the old pages carried it, check that every kind of new page carries it too.
• Keep internal links pointing at real pages. Change the links inside your own pages to the new addresses, so visitors and crawlers do not pass through a forward on every click. When I merged the guides, I rewrote every published link to an old guide address to point at the merged guide.
• Check robots and noindex on staging, then on live. Staging is the private copy of the new site you build on, and it should stay out of search. The usual way is a noindex tag, a line in the page that asks search engines not to list it. The other is a block in robots.txt, the file that tells crawlers where they may go. Both are right on staging and ruinous on the live site. Google’s guide names leftover blocks among the common mistakes of a move. While you are in the page source, check that the canonical tag names the live address, never the staging copy.

After launch, Search Console shows what the map missed if you keep looking

Launch day is the middle of the job, not the end of it.

• Submit the new sitemap. A sitemap is a file that lists every address you want search engines to find. Submit it in Search Console and in Bing Webmaster Tools on launch day.
• Watch the 404s and the indexing report. Search Console’s Page indexing report lists the addresses Google could not index, and why. Its “Not found (404)” row is where the forwards your map missed show up. Google’s site move guide says a medium-sized site can take a few weeks or more before the new addresses show. Check every week for at least the first month. My three came from a check like this one.
• Crawl your old list against the new site. Run the list from before launch through the crawler again. Every row should answer either a 301 that lands on a working page or a 404 you chose. A working page answers 200, the code for “here it is”.
• Compare impressions and clicks. Put the same weeks before and after side by side in the Performance report, for the pages that mattered. Google warns that rankings can fluctuate while it recrawls a site whose addresses changed, so judge the trend over weeks, not the first few days.
• Keep the forwards. Google’s site move guide says to keep redirects for as long as possible, generally at least a year. I see no reason to ever take one down.

One test this week shows whether your current site would survive a redesign

You do not need a redesign date to start. This week, export the Pages report from Search Console for the last 16 months and check every address on it. Each one should answer 200, or a 301 to a page that answers 200. A crawler in list mode checks the whole export at once. Without one, this line in a terminal checks a single address. It prints the code it answers with, and where a forward leads:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" https://www.example.com/old-page/

On Windows, type curl.exe in place of curl.

Any 404 on that list is a page that earned a place in search and now leads nowhere, before a redesign has moved a single page. Fix those first. Then keep the file. It is the first column of your redirect map.

My website redesign service covers the redesign and the search work that keeps it found. If you want a written record of what you have before you decide anything, start with the audit. Pricing has the rest.