Website redesign SEO: what to protect before launch

Website redesign SEO comes down to one idea: Google has learned where your pages are and what they say, and a redesign can quietly throw that knowledge away. Most ranking drops after a new site goes live aren’t caused by the design itself. They come from a handful of preventable mistakes made in the weeks before and the day of launch.

This explainer covers how those mistakes happen, what a WA business should record before any work starts, and the checks to insist on from your web developer. It’s written for owners and marketing managers, not developers, so the focus is on what to ask for and how to confirm it was done.

Why redesigns lose rankings

Search engines rank individual pages, not whole websites. Each page that ranks has built up signals over time: links from other sites, a history of being clicked, and content that matches what people search for. When a redesign changes that page’s address, removes it or rewrites it, those signals can be lost.

The most common causes are simple. Old URLs disappear without being redirected, so links and bookmarks lead to error pages. Pages that ranked well get merged or cut because they didn’t fit the new layout. Page titles and headings get rewritten for style without anyone checking what they used to target.

Then there are the technical slips. A staging site is left open and Google indexes it as a copy. A setting that told search engines to stay away from the staging site gets carried across to the live site. Internal links still point at old addresses, creating long chains of redirects. Any one of these can cause a drop, and they often arrive together.

What to record before you start

You can’t protect what you haven’t measured. Before a single page is redesigned, take a snapshot of the current site so there’s something to compare against later. Ask your developer or SEO provider to deliver these records, and keep a copy yourself.

• A full list of current URLs, taken from a crawl of the site and from the XML sitemap.
• The pages that bring organic visits and enquiries, exported from Google Analytics and Search Console for at least the last twelve months.
• The search queries each important page ranks for, from the Search Console Performance report.
• Pages that other websites link to, so none of them are dropped by accident.
• Current page titles, meta descriptions and main headings for every page you plan to keep.
• Any tracking that’s in place, such as enquiry form events and call tracking.

For a Subiaco professional firm or an Osborne Park engineering supplier, this might be a few dozen pages. For a business with a large product or project catalogue, it could be hundreds. Either way, the list becomes the master record that every later decision is checked against.

Redirects, staging and launch day

The redirect map is the single most important document in a redesign. It lists every old URL and the new URL it should point to, using permanent (301) redirects. Each old page should redirect to the closest matching new page, not to the homepage. Sending everything to the homepage is a common shortcut, and it usually throws away the relevance that page had built up.

Check the map for chains. If an old page already redirected somewhere and now redirects again, the developer should point it straight to its final destination. Long chains slow crawling and can weaken the signal passed along.

Staging needs its own controls. The test site should sit behind a password, which keeps both search engines and the public out. A robots.txt block or a noindex tag can also be used on staging, but these are exactly the settings that get copied to the live site by mistake, so they need a specific check at launch.

On launch day, ask for the redirects to go live at the same moment as the new site. Then confirm the new site can be crawled, the noindex tags are gone, the XML sitemap lists the new URLs and has been submitted in Search Console, and your enquiry forms and tracking still work. Google’s own guidance on moving a site with URL changes is worth sharing with your developer before work begins.

Website redesign SEO checks after launch

The weeks after launch are when problems surface, so plan for them rather than hoping they won’t happen. Some movement in rankings is normal while Google recrawls the site. What matters is spotting real faults early.

In the first week, test a sample of old URLs from your master list and confirm each one lands on the right new page. Check the Page indexing report in Search Console for a rise in pages that can’t be found or are excluded. Look at your top pages one by one and confirm their titles and headings still match the searches they used to win.

Over the following weeks, compare the Search Console Performance data with the snapshot you took before launch. Look at specific pages and queries rather than total traffic, because a site wide figure can hide a serious drop on one important page. If a key page has lost ground, check its redirect, its content and its internal links before assuming Google simply needs more time. Recovery timing varies, and for most businesses it depends on how many of these basics were done right.

Be clear about who owns each check. Your developer should own the redirects, staging and technical setup. Someone on your side should own the before and after comparison, because they know which pages bring the enquiries. If no one has the time or skills, independent technical SEO support in Perth can run the checks alongside your developer.

A redesign done this way can leave a site in better shape than before. The new structure is cleaner, the pages that matter are protected, and you have a record of what worked. For broader help with search, our team at Perth SEO works with businesses across WA.

The bottom line

• Record every URL, top page and ranking query before the redesign starts.
• Insist on a page by page redirect map, with no chains and no homepage shortcuts.
• Check for leftover noindex tags and a submitted sitemap on launch day.
• Compare page level Search Console data against your snapshot for several weeks after launch.