Website Redesign

The three ways a redesign loses search traffic

Redesigns that damage a business do it in one of three specific ways. They are different problems with different fixes, and most agency pages blur them into a vague warning about "SEO considerations". Separating them is the whole job.

One: URLs change and nothing redirects. A page that lived at one address for eight years now lives at another. Every inbound link, bookmark, directory listing and accumulated ranking signal points at the old string. Without a permanent redirect the old address returns a not-found error and the new page starts from nothing. This is the loud failure — it appears in Search Console within days, and at least you know what happened.

Two: the content is removed. The old page had nine hundred words the owner wrote himself, in the vocabulary customers use — aerobic septic spray field, Cedar Creek Lake dock permit, what to do when the aerator alarm goes off. The new design is cleaner: ninety words and a large photograph. Same address, redirects fine, no errors anywhere. The page simply no longer contains what people were searching for. This is the quiet failure, by far the most common one, and almost nobody connects it to the redesign because nothing appears broken.

Three: the template swallows the text. Sliders, tabs, accordions and image-only bands move copy into places where it is either absent from the page's HTML or only appears after scripts run. Because indexing uses the mobile rendering, copy the mobile layout drops is copy at risk. A related version: the new theme puts the page heading inside an image, or uses the business name as the top-level heading on every page.

What must be measured before the old site comes down

All of this must be captured while the old site is still live. Once it is gone, most of it is gone permanently. This checklist is the practical value of hiring anyone for a rebuild, and it is the first thing dropped when a project runs late.

• A full URL inventory. A crawl of every address that currently returns a page, exported to a file. This becomes the left-hand column of the redirect map — not a list typed from memory of the navigation menu.
• Search Console performance data, exported by page and by query, for the full window still available. That history is finite and it does not come back.
• The Search Console indexing report. Which addresses Google actually has indexed, as opposed to which exist. The gap between those two lists is often the most interesting thing in the project.
• Analytics landing pages for the last twelve months, with sessions and conversions. Without this, "we lost traffic" cannot be attributed to specific pages and every later conversation is opinion.
• Backlinks by target address. Old addresses with real external links are the redirects that matter most; the rest is hygiene.
• A saved copy of the old site's text. A complete crawl written to disk — the cheapest insurance in the project, and hardly anybody does it. In month three, when somebody says the old site explained the warranty better, you can go and get it.
• The old sitemap file, saved.
• Baseline call volume and form submissions, so there is a "before" to compare against.
• Screenshots of the key pages, so nobody reconstructs from memory what changed.
• DNS records, exported in full — mail exchange, SPF, DKIM, DMARC and verification records. Redesigns break email when the domain moves and somebody rebuilds DNS from memory. The site coming back is a bad afternoon; the email not arriving for two days is a real business problem.

Redirects are mapped, not guessed

The authoritative document is Google's own site move with URL changes guidance. It is short, and it settles most arguments.

• Use server-side permanent redirects where technically possible. Google supports several kinds and recommends HTTP permanent redirects such as 301 and 308.
• Redirect to the final destination directly. Googlebot can follow a chain of up to ten hops, but Google advises against relying on it; where a chain is unavoidable it should ideally be no more than three and fewer than five.
• Keep the redirects at least a year. Google states this window lets it transfer all signals to the new addresses, including recrawling and reassigning links on other sites. A redirect file deleted after two months during a server cleanup undoes the migration.
• Update the canonical tags, point internal links at the new addresses, publish a sitemap of them, verify both properties in Search Console before launch, and check the server can absorb the increased crawl rate Google applies during a move.

The map itself is built from the crawl, one row per address, with a human deciding the destination for anything that is not an obvious match. Every old address goes to the closest equivalent page. A retired service page goes to the service that replaced it, not to the homepage.

Redirecting everything to the homepage is the classic shortcut and it fails twice. Google treats mass redirects to an irrelevant destination as soft not-found responses, so signals do not transfer. And the visitor who clicked a link about dock permits lands on a homepage, does not find dock permits, and leaves. You have converted a specific answer into a generic one.

Launch-day failures, including the ones Google names itself

Google publishes its own list of migration pitfalls, and the first one has ended more launches than everything else combined.

• The noindex tag that protected staging is still there. The site launches perfectly and instructs Google not to index any of it. Nothing looks wrong; rankings disappear over the following weeks. Check on launch day, then again the next morning.
• A robots file left blocking the site, same reason, same result.
• Redirects pointing at pages that do not exist, because the map was written against the plan rather than the site as built.
• Staging left publicly reachable, producing a complete duplicate at a second address.
• The new property not verified in Search Console before launch, so there is no data for the first few weeks — precisely the weeks you need it. Verification is free; do it a month early. Google's performance report documentation is worth skimming so you know what you are looking at.
• The certificate lagging the DNS cutover, so day one greets visitors with a browser security warning. This is the version customers phone you about.
• Relaunching in your busiest month. Not a lawn care site in April, not a tax preparer in February.

When a redesign is not the problem

This is the section most likely to cost us a sale, and we would rather write it than not.

When the problem is that nobody visits. If the site receives forty sessions a month, a redesign produces a prettier page that forty people see. The bottleneck is acquisition — the Google Business Profile, reviews, listings, possibly ads. Reviews especially: BrightLocal's 2026 survey found around three quarters of consumers want reviews posted within the last three months, and that Google's share of review reading has fallen while AI assistants have climbed to third place as a source. A business whose newest review is five years old has a review problem, and no amount of new layout fixes it.

When the site is dated but working. A 2016 site that is usable on a phone, loads quickly, and has correct hours and a tappable phone number is doing its job. "It looks old" is a legitimate branding reason to rebuild and we will happily take that work. It is not a performance reason, and we will not dress one up as the other — because when the traffic does not change afterward, you will remember which one you were sold.

When the real complaint is "I cannot edit it myself." That is an access or training problem, usually solved with a login, a walkthrough and an hour.

When the real complaint is "it is slow." Measure first. The cause is almost always oversized images, fixable on the existing site in an afternoon. Failing the speed thresholds is also normal rather than exceptional: HTTP Archive's July 2025 data found fewer than half of sites passing all three Core Web Vitals on mobile.

When there is no budget left for content. A redesign that reuses thin copy produces prettier thin copy. If the money only stretches to design, spend it on writing instead. Copy survives the next redesign; a theme does not.

The safest redesign changes zero URLs

Worth stating on its own, because it inverts what most people assume they are buying. Nobody needs an "SEO-friendly redesign" that changes every address on the site. The safest redesign changes none of them.

If the existing structure is sane — readable, consistent, no session identifiers, no duplicate paths for the same page — keeping it eliminates the loudest failure mode entirely. You get a new design, new content and a new platform with no redirect map and no year of watching a spreadsheet.

Addresses are worth changing when they are genuinely broken: parameters where words should be, dates baked into paths for pages that are not news, a structure that made sense to a developer in 2011 and to nobody since. When that is the case, change them once, map every one, and keep the redirects indefinitely rather than for the minimum year.

How a rebuild is scoped and what drives its cost

Current figures are published elsewhere on this site from a single source rather than typed into paragraphs where they would go stale unnoticed. What varies between rebuilds is this. How many pages, and who writes them — supplying your own copy is a different job from having somebody interview you and write it. Whether addresses change, since a rebuild on the same structure skips the inventory, the map and the monitoring. Whether the platform changes, which adds content migration and a form-by-form check that everything still submits somewhere a human reads. How much has to be preserved — three hundred pages of accumulated content is a careful job; nine pages is not.

And what happens after launch. A migration is not finished on launch day. It is finished when the new addresses are indexed, the redirects have been checked against the live site, the error report is clean and traffic has settled. Budget for the four weeks afterward, and ask whoever quotes you whether they have. We have been doing this from Kaufman since 2003, and we will tell you before we start if we think the rebuild is not what you need.