SOUTHERN STANDARD
The page was a plain service page: one trade, one city, a few hundred words and a phone number. Nothing clever. It had been sitting around position four for over a year and it was the single best-performing page on the site: more organic traffic than the homepage, and the only page where people actually called from the listing.
Six weeks before I looked at it, the contractor had paid somebody to rebuild the site. New design, new platform, same content. It looked considerably better. And the URL for that page had gone from /ac-repair-wilmington to /services/ac-repair, with nothing telling Google the page had moved.
Why it hadn't broken yet
This is the part that makes it dangerous. Six weeks in, the page was still ranking. Still at four. Still getting calls. The contractor had no reason to think anything was wrong, because from where he sat, nothing was.
Google does not re-check every page on your site every day. It crawls on a schedule it decides, based on how often your site changes and how important it thinks the page is. For a small contractor site, a given page might go weeks between crawls. Until Google comes back around, the old URL stays in the index with its old ranking, serving traffic to a page that no longer exists.
The ranking doesn't disappear when the page does. It disappears the next time Google checks.
What was actually happening: anybody clicking that result got a 404. Google hadn't noticed yet. The moment it recrawled, it would drop the URL from the index, and a year of accumulated ranking on the best page on the site would go with it, not to the new URL, which Google had no reason to connect to the old one, but nowhere.
The fix is one line
A 301 redirect is a permanent instruction: this page moved, here is where it went, send everything to the new address. Google passes the ranking history across. Anyone clicking an old link from a directory, an old Facebook post, or their own bookmarks lands on the right page instead of an error.
It is genuinely one line of configuration. On most hosts it's a _redirects file or a redirect rule in the dashboard. The reason it doesn't get done isn't difficulty. It's that the person rebuilding the site is thinking about the new site, and old URLs are not part of the new site.
What we did
- Pulled every URL Google had indexed for the old site.
- Matched each one to its closest equivalent on the new site.
- Set a 301 on every match. Pages with no equivalent went to the relevant service page, not the homepage. A redirect to the homepage tells Google the old page had nothing specific about it.
- Resubmitted the sitemap so the recrawl happened on our schedule rather than Google's.
The page kept its position. The whole thing took under an hour.
Check this on your own site in ten minutes
If your site has been rebuilt, redesigned, or moved platforms in the last two years, do this today:
- Open Google and search
site:yourdomain.com. That's every page Google currently has indexed. - Click through ten or fifteen of them, especially anything that looks like an old URL structure.
- Any that land on a 404, a "page not found", or bounce you to the homepage is a page that will disappear on the next crawl.
- If you have Google Search Console, Pages → Not indexed gives you the same list without the guessing.
A redirect to the homepage counts as broken for this purpose. It stops the 404 but it doesn't carry the ranking.
The part worth remembering
Nobody did anything wrong here in an obvious way. The new site was better than the old one. The content was all still there. The failure was in the gap between two jobs. The person building the new site wasn't responsible for the old one, and the contractor didn't know there was a handoff to supervise.
That's most of what I find. Not incompetence. Just nobody holding the piece in the middle.
Written by Matt Pulliam, Southern Standard Systems. Details changed to keep the business anonymous; the failure is exactly as found.