Your General Contractor's New Website Launched Last Month — Google Still Ranks the Old One
A general contractor in Redondo Beach spent $14,000 on a new website last spring. Faster load times, better photos, a cleaner quote form. Three weeks after launch, organic traffic dropped 61%. Phone calls from search dried up almost entirely. The owner assumed Google was "still indexing" the new site and gave it time. Four months later, nothing had recovered. The old site — ugly, slow, built on a WordPress theme from 2017 — was still showing up in search results, except now it returned a 404 when anyone clicked it.
This isn't a rare accident. It's the default outcome of almost every website redesign in the trades that doesn't treat the migration itself as the project — not the new homepage, not the new photos, the migration.
The New Site Isn't Broken — The Bridge Between the Old One and the New One Is
Every URL on your old site accumulated something Google can't see on a dashboard but tracks internally: authority. Years of backlinks from supplier directories, local news mentions, chamber of commerce listings, license verification sites — all of it pointed at specific URLs. yoursite.com/services/adu-construction, yoursite.com/torrance-kitchen-remodel, whatever the old structure was. Google didn't rank your homepage for "ADU contractor Torrance." It ranked that specific page, built on years of signals tied to that specific address.
When a new site launches with a new URL structure — cleaner slugs, new categories, a different CMS — those old addresses stop existing. If nothing redirects /torrance-kitchen-remodel to its new equivalent, that page returns a 404. Google doesn't guess where the content moved. It treats the old URL as dead and the new URL as unproven. You don't inherit the old page's authority. You start over, except now you're competing against your own history — because for months, Google still has that old URL cached and still tries to serve it in search results, sending users to a dead page while your new one sits invisible.
This is the failure mode almost nobody in the trades diagnoses correctly, because it doesn't look like an SEO problem. It looks like "the new site just needs time." It doesn't need time. It needs a redirect map that was supposed to exist before launch and doesn't.
Why a 302 Redirect Is Worse Than No Redirect at All
Most contractors who do think about this get one detail wrong that costs them just as much as skipping it entirely: they use a 302 (temporary) redirect instead of a 301 (permanent) redirect, usually because that's the default setting in whatever page builder or hosting panel they're using.
A 301 tells Google explicitly: this content has permanently moved, transfer the ranking signals to the new URL. A 302 tells Google: this is temporary, keep evaluating the old URL as the real one. Run a site through a 302 migration and Google will sit for months treating your old, now-blank page as the canonical version — while your new page, the one you're actually paying to have built, gets none of the equity. We've audited South Bay contractor sites eighteen months post-launch still bleeding rankings because every redirect fired as a 302 by default and nobody checked.
Then there's the redirect chain problem, which is subtler and just as costly. A page moves from Domain A to Domain B, then six months later the URL structure on Domain B changes again for a "cleanup," so now it's A → B → C, three hops deep. Google follows redirect chains, but it discounts the authority passed with each hop, and after three or four hops it may simply stop following the chain and index nothing. Every general contractor who's rebuilt their site twice in five years — once for a new brand, once for a new developer — is very likely sitting on redirect chains nobody has ever mapped, quietly leaking authority at every hop.
The Systems Reason This Keeps Happening: Nobody Owns the Migration
Web design agencies build websites. SEO vendors run campaigns. Almost nobody sits at the intersection of both, which is exactly where a migration lives. The web design shop hands over a finished site and considers the job done — the URLs are whatever the new CMS generated by default. The SEO contractor, if there is one, gets looped in after launch, once the damage is already indexed. Nobody did the unglamorous work beforehand: exporting every indexed URL from Google Search Console, mapping each one to its new equivalent, writing a 301 rule for every single one, and testing the redirect chain end to end before the DNS switch.
This is a systems failure, not a competence failure. It happens because redesigns get treated as a design decision with SEO as an afterthought, when a migration is actually the single highest-risk SEO event a business will ever go through — riskier than a Google algorithm update, because an algorithm update might cost you a few positions. A botched migration can cost you the page entirely.
What a Migration Built to Preserve Rankings Actually Looks Like
Before a single line of the new site goes live, every indexed URL gets pulled from Google Search Console's performance report and pulled again from a full site crawl — not just the URLs someone remembers, all of them, including the orphaned service page from 2019 that still gets three organic clicks a month from a five-year-old backlink. Each one gets mapped to its closest equivalent on the new site. Every redirect fires as a 301, tested with a header checker before launch, not assumed. Redirect chains from prior migrations get collapsed to a single hop — A goes straight to C, not through B.
Canonical tags on the new site get set to self-reference correctly, so Google isn't left guessing which version of a URL — with or without a trailing slash, with or without "www" — is the one that counts. An updated XML sitemap gets submitted to Search Console the day the new site goes live, and a change-of-address signal gets filed if the domain itself changed. Then for the following ninety days, someone is actually watching Search Console weekly — not glancing at analytics, checking crawl stats, indexed page counts, and 404 reports, catching a missed redirect in week two instead of discovering it in month four when the phone stopped ringing.
This is precisely the discipline that separates a custom-coded rebuild done by people who understand what a general contractor's rankings are actually worth from a template swap done by a design shop treating the URL structure as a cosmetic detail. The site can hit 98 on PageSpeed and still lose every ranking it earned if the migration underneath it was never engineered.
The Old Site Was Ugly. It Was Also the Only Thing Google Trusted.
Here's the uncomfortable part: the old site, slow and dated as it was, had earned something real — years of Google slowly deciding it could trust those specific pages to answer specific searches. A redesign doesn't inherit that trust automatically. It has to be transferred, deliberately, URL by URL, or it evaporates the day the new site goes live.
If your business has redesigned in the last year, or is about to, the question worth answering right now isn't whether the new site looks better. It's whether every URL that used to rank has a working, single-hop, 301 redirect pointing at its replacement — and whether anyone actually checked. For general contractors especially, where a single commercial or ADU project can be worth six figures, that's not a technical footnote. That's the difference between a redesign that compounds a decade of earned authority and one that quietly resets the clock to zero.
If you're planning a rebuild, or you already launched one and can't explain the traffic drop, that conversation is worth having before more months pass. The fix gets cheaper every week you catch it early, and considerably more expensive every month you don't.