The risk in a small business website redesign is set before the design starts. Google's site-move guidance begins with a listing of old URLs and a decision on where each one should redirect, so a page nobody listed cannot be mapped. Inventory every live URL, record what it earns in search clicks, enquiries and AI citations, and give each one an action before switch-off.
The new site's risks are real, but they are the visible ones. The quieter risk sits on the old site, in the service page behind most of your enquiries, the guide that still pulls organic clicks, the article an AI answer keeps citing. A typical redesign brief describes the site you want and says almost nothing about the site you have.
Google is candid about what happens when that gap meets a launch. Its site moves and migrations guidance, last updated 20 August 2026, warns: "With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site." So the damage a redesign does is largely decided before anyone opens a design file, at the moment someone does or doesn't write down which URLs are earning. Treat the content inventory as the redesign's real brief, and every live URL reaches launch with a measured baseline and a decision attached.
The brief nobody writes: what is the old site already earning?
A redesign brief is usually a wish list: the positioning, the look, the features the new site needs. That covers half the job. The other half is an honest record of what the current site already does for the business, and the inventory is the only point at which "which pages carry pipeline" gets written down before anyone changes a URL.
Think of it as the removalist's inventory before a house move. Nobody can claim for a box that never made the list, and nobody can prove a redesign lost a page that was never recorded.
HubSpot, which sells content management software of its own, draws the distinction in its content inventory playbook. An inventory answers "What do we have?" An audit answers "What should we do with it?" Teams usually build the inventory first, then add audit fields such as Action, Priority and Notes to the same tracker (the playbook notes that Nielsen Norman Group recommends one tool to house both). HubSpot also says when: run a broader review "before a site migration, redesign, strategy reset, or major audit", refreshing performance data and recording the reporting window.
Switch-off is harder than it looks, even at national scale. After the Bureau of Meteorology's rebuilt site launched in October 2025, iTnews reported that the BoM still relies on its legacy site, and by February 2026 the bureau had set out a six-month plan of fixes after user complaints. That is an extreme public-sector case about users and functions, not search traffic, and iTnews reports the BoM never planned to retire the legacy site. The point for a smaller site is the reverse: you can only switch off what you have fully accounted for.
Inventory first, audit second: what a small business website redesign needs on every row
Start with scope, because the job sets it. In HubSpot's example, a migration project may require every live and redirected URL, while a topic-cluster review may need only the relevant blog posts. Write down the goal, the included and excluded properties (subdomains count), the date range, the source systems and the intended output before you collect a single URL. Then the fields, most of which earn their place in a redesign:
- Identity: a stable ID and the full URL, with one row per canonical URL, plus title, H1 and meta description.
- Context: content type, owner, a controlled status (Published, Draft, Needs review, Retired), and the original publish date and last substantive update, which the playbook treats as review signals rather than proof a page is stale.
- Purpose: the primary search target, the business goal, the journey stage and the primary CTA, recorded "so the team can connect content to its conversion path".
- Decision: Keep, Update, Consolidate, Redirect, Remove or Create, with the evidence and the next step.
Order matters. Import what a crawler can read first, then add what tools cannot reliably determine: content type, owner, business goal, journey stage, primary CTA and audit notes. Machines do the counting. People do the judgement.
For a redesign, three columns decide the priority of every row. Call them the earning columns.
| Earning column | Where it comes from | What it protects |
| Organic demand | Google Search Console clicks and impressions | Pages that bring people in from search |
| Enquiries | GA4 key events against the page's primary CTA | Pages that turn visits into pipeline |
| AI citations | A manual check of whether the URL is cited in AI answers to your priority buyer queries | Pages AI answers already point to |
The third column needs a caveat. HubSpot positions its own AI Search Grader as a brand-level signal of how ChatGPT, Perplexity and Gemini represent a brand, to be used alongside page-level search and analytics data. The page-level column is our addition, and it is directional at best: AI citation tracking is not settled measurement, and "AI search visibility" remains a contested label rather than a discipline with fixed rules. A structural self-assessment of AI citations covers that check in depth. For an inventory, a yes, no or unknown per priority URL is enough; tracking it continuously is the job of AI visibility measurement.
HubSpot also cautions that no single metric proves a page is good, bad or ready for removal. Use the same reporting window for every row, label it, preserve the extraction date, and weigh performance against business value, accuracy, links, conversions and search intent before you assign an action.
Why a crawl alone misses the pages that matter most
A crawler is where most inventories start, and it should be. Run one for status code, indexability, canonical, title, meta description and H1, and you have the machine-readable half of a website technical audit checklist. HubSpot's author started a client site's inventory exactly that way, with a Screaming Frog crawl enriched in a spreadsheet. The free version crawls up to 500 URLs per crawl, and a paid licence costs US$279 per user per year, as HubSpot publishes it.
The catch lies in how a crawler finds pages: by following links. Picture a campaign landing page that nothing on the site links to any more, still collecting enquiries from an old email signature. A link-based crawl won't find it. HubSpot's answer is to compare the crawl with XML sitemaps, analytics landing pages, Search Console pages, CMS records and any migration or redirect files, a reconciliation that "can uncover orphaned pages, noindexed pages, and other URLs that a link-based crawl may not discover." Google's site-move guidance points to overlapping sources for the old-URL list: "Look in your sitemaps", "Check your server logs or analytics software for the URLs that get the most traffic", and "Check the Links to your site feature in Search Console".
One piece of HubSpot's advice needs adjusting for a redesign. If a full-site inventory exceeds capacity, the playbook suggests completing one high-priority section end-to-end as a pilot. That works for enrichment: fill the earning columns for your top sections first. It fails for coverage. Every live URL needs a disposition before switch-off, because the pages nobody listed are the ones that 404.
Keep, update, consolidate, redirect, remove: decide before the designer does
Let's start with the two actions that sound alike and do different jobs. HubSpot draws the line cleanly: consolidation is a content decision, combining useful material from overlapping pages into one stronger primary page, while a redirect is a technical instruction, a permanent server-side redirect that sends users and search engines from a retired URL to a relevant successor. Consolidation often leads to a redirect, but the two are not interchangeable. The reasoning behind which pages to merge belongs to content pruning for AI search; in the inventory, Consolidate is one row value.
Google backs the redirect half closely. It tells site owners to "map your old site's URLs to the URLs for the new site" and, once they have the listing of old URLs, to "decide where each one should redirect to". It asks for server-side permanent redirects where technically possible, warns against chaining them, and names the shortcut teams reach for: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site." HubSpot says the same in plainer terms: don't send removed pages to an unrelated homepage merely to avoid a 404. The redirects then stay. "Keep the redirects for as long as possible, generally at least 1 year," Google advises, which gives it time to transfer signals and reassign links from other sites that point at the old URLs. If the new information architecture changes URL paths, the redirect map is where those decisions get recorded, and it is core technical SEO work rather than a developer's afterthought.
The clearest public-sector template comes from the UK. GOV.UK's guidance for transitioning content, last updated 13 November 2024, tells agencies to audit for what is "the most used or has highest impact", "out of date" or "duplicating content already on GOV.UK or elsewhere", then "create a spreadsheet of all your website's URLs and where each one needs to redirect to", and ask The National Archives to capture the old site 4 weeks before closure. None of that binds a private firm, but it is long-standing practice worth borrowing, archive step included, because a snapshot of the old site belongs in the baseline.
The AI-citation column depends on these decisions too. Google's documentation on AI features and your website, last updated 10 December 2025, is specific: "To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet, fulfilling the Search technical requirements." Our reading, which is reasoning rather than anything Google states: a cited URL that stops resolving falls out of that eligibility, and the path the citation used breaks with it. The page says nothing about how a citation carries through a redirect, and it covers Google's AI Mode and AI Overviews only, not ChatGPT or Perplexity. A relevant redirect is the best protection available, with no guarantee attached.
Don't lose the instruments: keeping measurement intact through the rebuild
A loss you never measured can't be proved or fixed. Without a frozen pre-launch baseline on identical definitions and date windows, nobody can separate a post-launch dip from seasonality or a tracking change, so nobody can show the redesign caused it or that the fix worked. Google's timeline stretches that window: "for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer)." It tells owners to "monitor how the user and crawler traffic changes on the new site and also the old site", and its rule to "Change only one thing at a time" puts a new layout on the same list as a new domain and a CMS change.
How large can the losses get? We found no dated study with a stated sample of same-domain redesigns, only case studies and opinion. The closest evidence is Dan Taylor's study of 892 domain migrations for Search Engine Journal: on average, it took 523 days for the new domain to reach the old domain's level of organic traffic, and 17% of migrations in the sample hadn't recovered after 1,000 days. Read it with its limits. It covers domain moves, not redesigns; the traffic figures are Ahrefs estimates rather than analytics data; the sample was partly crowdsourced from SEO professionals; and the author notes wide variation between sites. Sophie Brannon, writing for Search Engine Journal on the migration hangover traffic drop, puts a normal, temporary dip at 10% to 30% and a damaging hangover at 50% or more, explicitly from her own experience rather than a measured sample.
The instruments have to move as well. Webflow's Google tag gateway announcement is one platform's example of a general point: sites that measure with Google tag snippets pasted into custom header or footer code should "safely migrate to the native integration and prevent data discrepancies", and set a consent configuration "to maintain compliant consent management and accurate tracking". Whatever your platform, the inventory should record which tags run on which pages and whether each one serves analytics or advertising, because a rebuild re-implements every one of them.
That re-implementation is also a compliance checkpoint. In Australia, the Privacy Commissioner issued two tracking-pixel determinations on 24 June 2026, finding that telehealth provider Medmate Australia and fertility provider Monash IVF interfered with privacy by collecting sensitive information through third-party pixels. The OAIC says website providers "must obtain consent where they're using tracking pixels to collect sensitive information, such as data on health, political opinions, race or ethnicity". Keep the scope narrow: both cases involve health-related sites and sensitive information, and they do not mean every Australian analytics tag needs consent. The OAIC's tracking pixels and privacy obligations guidance notes the Privacy Act does not prohibit pixels, but expects due diligence, minimised collection (APP 3) and disclosure in privacy policies and notices (APPs 1 and 5). If your pages touch sensitive topics, re-adding pixels to a new site is the moment to check them. That is a prompt to check, not legal advice.
UK sites face a different rulebook. The ICO's final storage and access technologies guidance, published 29 April 2026 and incorporating changes from the Data (Use and Access) Act, includes a 'statistical purposes' exception. Analytics storage can run without consent only if its sole purpose is statistics about how the service is used "with a view to making improvements to the service", users get clear information and "a simple and free means to object", and any third-party analytics provider acts as a processor. The ICO's guidance on the exceptions is explicit: "The statistical purposes exception does not apply to purposes related to online advertising." Advertising and conversion tags still need consent, and the exception is no licence to drop the cookie banner.
Key takeaways
- Brief the old site before the new one. Inventory every live and redirected URL before design starts, and record the reporting window and extraction date alongside the data.
- Score every row on its earning columns: Search Console clicks and impressions, GA4 key events against the primary CTA, and a manual AI-citation check you treat as directional.
- Reconcile the crawl with XML sitemaps, analytics landing pages, Search Console, CMS records and existing redirect files. Pilot the enrichment by section if you must, but never the URL coverage.
- Map every retired URL to a relevant successor with a server-side permanent redirect, never a blanket homepage redirect, and keep the redirects for at least a year.
- Inventory the tags as well as the pages, separating analytics from advertising, and check them against OAIC or ICO guidance as you re-implement them.
Frequently asked questions
What should you do before a small business website redesign?
Build a content inventory of every live URL before design starts. Record each page's search clicks, enquiries and AI citations over one labelled reporting window, then assign it an action (keep, update, consolidate, redirect or remove) so no page reaches switch-off without a destination.
Will a website redesign hurt my Google rankings?
It can, at least temporarily. Google's site-move guidance says that with any significant change to a site you may experience ranking fluctuations while Google recrawls and reindexes it, and that for medium-sized sites it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (longer for larger sites).
How long should redirects stay in place after a website redesign?
Google advises keeping redirects for as long as possible, generally at least one year. That gives Google time to transfer signals to the new URLs, including reassigning links on other sites that still point to the old ones.
Can a redesign affect whether AI Overviews cite my pages?
It can, by reasoning from Google's documentation rather than from any published test. Google says a page must be indexed and eligible to be shown in Search with a snippet to appear as a supporting link in AI Overviews or AI Mode, so a cited URL that stops resolving loses that eligibility. Google does not say how citations carry through a redirect.
What is the difference between a content inventory and a content audit?
An inventory records what the site has, and an audit decides what to do with it. HubSpot's playbook recommends building the inventory first, then adding audit fields such as Action, Priority and Notes to the same tracker.
Know what the old site earns before it goes dark
Planning a rebuild? An Amina Website Review starts with the site you already have: which URLs earn traffic, enquiries and AI citations, and what each one needs before switch-off. A site can look modern and still be invisible. Amina builds websites that are fast, accessible, and structured so search engines and AI can actually read and cite them. See how Amina builds.
