The redesign that ranked before and does not rank now
Almost every redesign we are asked to quote arrives with the same sentence attached: the last one cost us traffic. Sometimes the owner is describing their own site. More often they heard it from somebody in their industry group who rebuilt three years ago and never got back to where they were.
The failure is real, and it is almost never a design failure. The pattern is consistent enough to recite. Traffic holds through the first week, because Google has not recrawled much yet. It slides through weeks two to six as the recrawl works through the site. By week eight somebody is explaining that the market softened.
What actually happened is usually one of five things. The URL pattern changed and everything old was redirected to the homepage. Redirects were built, but each one passes through two or three hops inherited from an earlier migration. The staging environment’s noindex tag shipped to production. A dozen thin-looking pages were consolidated into three good ones without anyone checking which of the twelve were earning. Or the navigation was rebuilt, and pages that were only ever reachable from the old footer lost their only internal path.
In the rebuilds that hold their positions, the pages still ranking afterwards are the same pages that ranked before, at recognisable URLs, with their content intact. That is the entire trick. A website redesign without losing SEO rankings is not a design problem. It is an inventory problem, solved before anyone opens a design file.
What actually carries ranking equity through a rebuild
Worth being precise about, because the list is shorter than most people assume and almost none of it is visual.
Carries equity:
- The URL itself. The cheapest artefact to preserve and the one most often discarded for tidiness. If the old URL still resolves, most of the problem never exists.
- A single-hop 301 to a genuinely equivalent page. Equivalent means it answers the same question. A service page pointed at another service page is a transfer. A service page pointed at the homepage is a discard, and Google treats it as a soft 404.
- Internal links. How many pages link to a page, and with what anchor text. This is a live ranking input that a new navigation rewrites silently.
- The substantive content. Headings, body copy, and the specifics — job details, price ranges, code requirements, place names. Cut sixty percent of a page’s words for a cleaner layout and you have changed what it can rank for.
- External links, but only through the redirect, and only when the destination is equivalent.
- Structured data that keeps its identifiers and points at the live URL.
Does not carry equity:
- The visual design. Colours, typography, hero treatment, layout.
- The CMS or hosting platform.
- Meta descriptions.
- Presence in the XML sitemap, on its own.
- Domain age, which you keep either way.
This is why a site can be rebuilt from nothing visually and hold every position it had — everything measured was preserved, and everything that changed was something Google does not read. It is also why a cosmetically minor refresh can lose half a site’s traffic, because underneath it the pages moved.
The redirect map: one row per old URL, no exceptions
The deliverable is a spreadsheet with five columns: old URL, its status code today, the new destination, the reason for that decision, and a verification tick once it has been tested. Not a rule in a config file. A row per URL, reviewed by a person.
Build the old URL list as a union of sources, because no single source is complete:
- A full crawl of the live site before anybody touches it
- Every URL with an impression across the sixteen months Search Console retains
- Server or CDN logs, which show what Google still requests
- Your backlink export, which contains URLs that already stopped existing
- The current XML sitemap
- An archive crawl, if a previous migration already lost pages
Then five rules decide whether the redirects after redesign actually work.
One-to-one, never a catch-all. Redirecting everything to the homepage is the single most common cause of a failed migration.
Single hop. If the old rules already send /a/ to /b/ and you add /b/ to /c/, rewrite the first rule. Chains inherited from a previous replatform are the reason equity leaks on sites where the map looks correct.
301, not 302. Temporary redirects are read as temporary.
One canonical form. Trailing slash or not, uppercase or lower, www or bare, http or https. Pick one and make every variant arrive in a single hop, or you will find four versions of the same page competing.
Record deletions deliberately. A page you are genuinely retiring should return a 410 or redirect to its parent category, with the reason written in the row. Silence is how a page disappears without anyone noticing it was earning.
Verify the whole map on staging before launch, then run it again against production within the first hour. Freeze content changes for two weeks beforehand so the map does not go stale while it is being checked.
Service-area and city pages: the ones everyone forgets
These are the pages that get lost, and the reason is organisational rather than technical. They sit outside the main navigation, they were never part of the design conversation, and on many sites they were built by whoever handled marketing two agencies ago. Nobody in the kickoff meeting has them in mind. Meanwhile they are frequently the pages ranking for the highest-intent local searches you get.
Three things break them during a rebuild. The URL pattern changes, so /tampa-web-design/ becomes /locations/tampa/ with no map behind it. Twelve area pages get consolidated into one areas-we-serve page that lists city names, which converts twelve ranking pages into zero. Or the new template has no field for the local detail — the neighbourhood names, the county permitting notes, the completed jobs — so it is dropped in the content migration and the page becomes generic.
The rule is simple: every service-area page keeps its own URL and its own body content through the rebuild. If you have concluded that you have too many of them, retire them one at a time after launch, where you can watch what each removal costs. Do not fold that decision into the migration, where the effect is unmeasurable.
The second half of this is internal linking. If the old footer linked fourteen area pages and the new footer links four, the other ten just lost most of the internal signal they were running on. Map the internal links deliberately into the new templates, the same way you mapped the URLs. Our St. Petersburg page shows the structure we build these into, and it is the same structure we try to preserve when a client arrives with pages that already work.
Your Google Business Profile website link points at a URL that may no longer exist
The day after launch, somebody should open the Google Business Profile and click every link in it. Most profiles point at the homepage and survive. Plenty do not.
Check all of it: the website field, the appointment or booking URL, any place action links, the service and product items that carry their own destinations, and the historical posts, which frequently link to specific pages that no longer resolve. If the website field carries UTM parameters — and it should — confirm the new site does not strip query strings on redirect, because that silently reassigns your profile traffic to direct.
Then widen the same check. Deep links pointing at your old URLs live in your citations and directory listings, your paid search final URLs, your email signature and invoice templates, and the link fields on every social profile you own. None of these break loudly. They just start redirecting, or stop working, and nobody tells you. The Google Business Profile checklist covers what those fields should contain in the first place; this is the post-launch pass over them.
Schema, tracking and call routing after launch
Three systems that live outside the design and therefore outside most build scopes.
Schema. Organization or LocalBusiness markup, service markup, breadcrumbs, FAQ blocks — new templates carry none of it unless it was specified. The identifiers and URL values inside the markup also need updating, or you ship structured data describing a site that no longer exists. Build it into the templates rather than bolting it on afterwards, because retrofitting means editing every page type twice.
Tracking. The measurement ID has to be present on every new template, not just the ones anybody remembered to check. Conversion events — form submissions, call button taps, chat opens — are defined against selectors and page paths that the rebuild changed, so they need recreating and testing rather than assuming. If the domain itself is changing, use the change of address tool in Search Console and verify the new property before launch, not after. Consent banners are a common culprit for tags that fire in testing and not in the wild.
Call routing. Dynamic number insertion scripts routinely do not survive a replatform. When the swap script fails, a tracking number gets published as your main number in the header, the footer and the schema — which contradicts the number on your Business Profile and every citation you own. Keep the real business number in the markup and the footer, and treat the swap as something to verify on every template before the site goes live.
When to relaunch in Florida: the hurricane and snowbird calendar
Two windows work in Tampa Bay: April to May, and late October. Everything else carries an avoidable risk.
Do not relaunch between June and November. A site that is two weeks old has no operational history. Nobody knows yet how it behaves under load, how the CDN caches it, or how quickly DNS propagates if you have to move something. A storm week is the week your customers are searching for you, your phone lines matter more than usual, and your staff are least available to sit in Search Console watching for a coverage spike. Combining a fresh migration with that week means you can lose rankings and phone coverage simultaneously, and for storm-exposed trades that week is a meaningful share of annual revenue.
Do not relaunch in the first quarter. January through March is when snowbird-season revenue peaks for retail, hospitality, medical practices, and anyone selling home services to seasonal residents. A dip during recrawl is normal and temporary; taking it during your strongest weeks costs several times what the same dip costs in a quiet month.
That leaves April and May — after the seasonal population thins, before hurricane season opens — and late October, once the statistical peak of the season has passed and before the winter arrivals begin. Inside those windows, launch on a Tuesday morning. A Friday afternoon launch means the person who can fix a broken redirect finds out about it on Sunday.
The 14-day post-launch check that catches a bad migration while it is still fixable
Migrations are recoverable in proportion to how quickly you notice. Run this on a schedule rather than by feel.
Hour one. Confirm the staging noindex tag did not ship and robots.txt is not blocking anything. Spot-check your twenty highest-traffic old URLs and confirm each returns a 200 or a single 301. Submit a test form. Check analytics is recording. Read the phone number on every template.
Day one. Crawl the entire old URL list and confirm every row resolves in one hop to the mapped destination. Submit the new XML sitemap. Verify canonical tags point at the live URL rather than at staging, which is a common and quiet failure.
Day three. Open Search Console coverage and watch for spikes in not-found, page-with-redirect, and alternate-page-with-canonical statuses. Use URL inspection on five important pages to confirm the rendered HTML contains the content — on JavaScript-heavy builds it sometimes does not.
Day seven. Compare clicks and impressions page by page against the equivalent weekday span before launch. A modest overall dip during recrawl is expected. A specific group of pages dropping to near zero is a defect.
Day fourteen. This is the decision point. For any page group that has lost more than half its impressions, check three things in order: does the redirect resolve in one hop, does the new page still contain the content the old one had, and do the internal links that pointed at it still exist. In our experience nearly every genuine loss at day fourteen fails on one of those three, and all three are cheap to fix at two weeks and expensive at six months.
Our website redesign work begins with this inventory rather than with a design, and the technical SEO side of the project is a named deliverable rather than something absorbed into the build. If you are holding a quote from somebody else, ask them for the redirect map and the launch date they are proposing. Those two answers tell you most of what you need to know — and if you want a sense of what the rest of the project should cost, we published our redesign pricing ranges for exactly that comparison.
