How to check whether a redesign hurt your Google rankings with Search Console

You find out whether a redesign hurt your search traffic by comparing how each page performed in Google before the launch with how its replacement performs after it. Google Search Console is the place to do that, because it records the clicks, impressions, click-through rate, and average position your pages earn in Google Search, broken down by page and by the query people searched. In the Performance report, set the date filter to Compare and choose two periods of equal length on either side of your launch date, such as the four weeks before and the four weeks after. Then switch to the Pages tab and sort by the difference in clicks.

Looking at the whole site first can mislead you in both directions. Total clicks can hold steady while your most valuable pages quietly lose their rankings, and totals can fall for reasons that have nothing to do with the redesign, such as a seasonal slowdown or a Google update in the same weeks. If your business is seasonal, compare against the same weeks last year as well. Leave out the last two or three days, because Search Console takes that long to finish processing its data.

Expect some movement in the first few weeks. Google has to recrawl your new pages and work out how they relate to the old ones, so positions often wobble before they settle. A dip that recovers within a few weeks is normal. A page that keeps losing clicks after that, or drops out of results entirely, is a real problem with a cause you can find.

The hard part is that a redesign often changes addresses. When an old page moves to a new address, Search Console shows the old address losing its clicks and the new address gaining some, as two unrelated rows. It doesn't tell you which new page replaced which old one, or whether the new page earns what the old one did. To answer that, you have to pair the addresses yourself, check that each old address redirects to the right new page, and compare what changed on the page.

Search Console helps with the next step. Its Pages report, under Indexing, lists addresses Google can't index and the reason, such as "Not found (404)", "Page with redirect", "Excluded by 'noindex' tag", or "Blocked by robots.txt". The URL Inspection tool shows whether one address is indexed, which canonical address Google chose for it, and when Google last crawled it. These tools show you the symptoms one address at a time, though. None of them tells you which losses matter most or what to fix first.

A good result is a short list: the pages that lost the most traffic since launch, each paired with the page that replaced it, the cause of each loss with the evidence behind it, and the fix, in order of how much traffic it should win back. Kite does that check for you.

Start by telling Kite in Slack when the new site went live:

"We launched our redesigned website on the 1st. Can you check whether it hurt our Google rankings?"

Kite is an AI marketer in your Slack. It researches your business, builds a growth strategy, and ships the work that brings you new customers. From that research, it already knows which pages matter most to your business, which searches you compete for, and who your competitors are. If Kite built and hosts your site, it also knows exactly when the new version was published and which addresses changed. If you're not sure of the launch date, Kite can work it out from archived copies of your site and from the day your Search Console data shifted.

Connect your Google account for Search Console through OAuth so Kite can read your performance and indexing data. If your account has access to more than one Search Console property, Kite lists them and confirms which one covers your site. A domain property is the most useful one for this check, because it combines every version of your address, so a move from http to https, or from www to no www, doesn't split your data in two.

Reading reports is routine work, so Kite starts as soon as the account is connected and posts its findings in the thread. It asks for your approval before it publishes any change to your site.

Kite starts by measuring the change against a fair comparison, so it isn't chasing an ordinary dip. It queries your Search Console performance by date for equal periods before and after launch, and it skips the most recent days that Google hasn't finished processing. It reads clicks, impressions, click-through rate, and average position for each day, which shows whether the change started on launch day or began earlier.

Kite then rules out the explanations that would have happened anyway. When your traffic is seasonal, it compares the same weeks last year. It searches the web for a confirmed Google update in the same window. It also tells you how long the new site has been live, because a drop in the first couple of weeks after launch can still be Google settling in, and Kite says so plainly when it's too early to call.

Kite finds the pages behind the change by querying Search Console by page for both periods. It ranks every address by how many clicks it lost and keeps the queries each page used to earn, because those queries are what the new page needs to win back. Usually a small group of pages accounts for most of the loss, and those pages get the rest of the investigation.

Kite also separates a page that lost some clicks from one that vanished from results. A vanished page usually has a technical cause, and a page that slipped a few positions usually has a content cause.

Kite pairs each old address with its replacement, because that's the only way to tell whether a page lost its rankings or simply moved. When Kite built the redesign, it reads the list of addresses that changed and the redirects it set up. Otherwise, it reads the old page from archived copies of your site and finds the new page that covers the same subject, using the title, the headings, and the queries the old page ranked for.

Then Kite opens each old address on your live site and records where it ends up. An old address can redirect to its matching new page, which is the result you want. It can also redirect to the homepage or a general category page, which Google often treats as a page that no longer exists, or it can return an error page. It can also pass through a chain of several redirects before it lands. Kite marks every old address that doesn't land directly on its replacement.

Kite checks that Google can reach each new page and is willing to index it. It inspects the most important new addresses in Search Console and reads their index status, the canonical address Google chose, and when Google last crawled them. It reads your sitemaps in Search Console, notes how many addresses each one submitted and any errors Google reported, and it checks that the sitemap lists the new addresses rather than the old ones.

On the live pages, Kite looks for the problems that a redesign tends to carry over from a staging site: a noindex tag left in place, a robots.txt rule that blocks the whole site, or a canonical tag that points to the staging address or to the wrong page. Each of these can take a page out of Google even when everything else is right.

For each page that kept its address or has a clear replacement but ranks lower, Kite compares the old version with the new one. It reads the archived copy of the old page and the live new page side by side and checks what changed:

• The title and the meta description that Google shows in results
• The main heading and the section headings
• The text itself, especially sections that answered the queries the page ranked for and were cut to fit the new design
• The internal links pointing to the page, since a page that used to sit in the main navigation and now sits three clicks deep usually loses ground
• The structured data and the page's speed on phones

Kite then uses its built-in keyword and ranking data to see who ranks for the lost queries now and reads the pages that moved ahead. That tells it whether the page lost ground because of what changed on it or because a competitor published something stronger in the same weeks. Kite treats a match in timing as a lead to check rather than as proof, and it says how confident it is in each cause.

Kite posts its findings in the Slack thread where you asked. It opens with the answer: whether search traffic fell since launch, by how much against which comparison, and how much of the change the redesign explains. Then it lists the pages that lost the most clicks, each with its replacement, the cause, the evidence, and the fix, in order of how much traffic the fix should win back. Every figure carries the dates it covers. When the findings are too long for one message, Kite publishes them as a findings page with tables and links to it from the thread.

From there, Kite can make the fixes. On a site Kite hosts, or one it works on through your GitHub repository, it adds permanent redirects from each old address straight to its matching new page, removes redirect chains, updates the sitemap, restores titles and headings, puts back content the old page ranked for, removes a stray noindex tag, and corrects canonical tags. It asks for your approval before publishing, and shortly after each publish it checks your site's sitemap, search basics, and speed again. On a site Kite updates through a supported CMS such as Webflow, it can restore the content the old pages ranked for. For a site Kite can't edit, it gives you the exact list of redirects and changes for whoever manages the site.

After the fixes go live, Kite resubmits your sitemap in Search Console so Google finds the new addresses sooner. Google takes days or weeks to recrawl and re-rank pages, so ask Kite to run the same check every week for the next couple of months, and it posts each week's results in the same thread so you can see the pages recover.

When Kite finishes, you know whether the redesign cost you search traffic, which pages lost it, and what to change to win it back.