Moving a 20-Year-Old Business Off WordPress Without Losing Its Rankings

You lose rankings in a migration when URLs disappear — not when the platform changes. Google ranks addresses, not CMSs. Keep every address resolving, either as itself or as a 301 to its closest match, and the rankings you earned have every reason to follow. The risk is never the static stack. The risk is an inventory nobody took.

The Critter Guy is portfolio work of ours — a wildlife-removal company two decades deep, moved off WordPress onto a static build. It is live at thecritterguy.ca: open it, run Lighthouse. Below is the method that gets a site there.

A three-year-old site has forty URLs and you know all of them. A twenty-year-old WordPress install has archaeology in it. Two permalink structures, three themes, a plugin someone installed in 2014 that quietly published a page for every image ever uploaded.

What is usually buried in there:

• Dead permalink formats still linked from somewhere — /?p=417, /index.php/services/, /2011/06/old-blog-post/
• Attachment pages, plus tag, category, author and date archives — mostly thin, a few of them earning clicks
• Feed endpoints, ?replytocom= comment URLs, tracking parameters that got indexed
• Protocol and host variants (http, https, www, trailing slash) and PDFs — permits, a 2016 brochure other sites still link to

None of that is exotic. All of it is invisible if your inventory method is clicking through the menu and writing down the pages.

One source always misses something. Four sources overlap enough to catch the gaps. We pull all four before a single line of the new site is written.

1. A full crawl of the live site. Every internal link followed, every response code recorded, chains flattened, canonicals captured. This is the site as it links to itself.
2. Search Console — the Pages report, exported. Indexed, not-indexed, excluded, all of it. This is the site as Google sees it, which is never the same list. Orphan pages nobody links to show up here, and some of them have impressions.
3. The old XML sitemap. Plugin-generated and usually stale — and the staleness is the point. It names URLs the current crawl no longer reaches.
4. Server access logs. The one nearly everybody skips. Logs show what is actually being requested: the PDF still getting hits from a forum post, the old campaign page, the URL a directory has pointed at since 2013. No crawler finds those.

Deduplicate the four lists into one sheet. On a long-lived site the merged list runs far longer than the owner expects, and a large share of it is cruft. That is fine. Cruft you have written down is a decision. Cruft you have not is a 404.

inventory = crawl + search-console + old-sitemap + access-logs
→ one row per URL
→ columns: status, template, clicks, impressions, inbound links, decision

"Every URL preserved or 301-redirected" does not mean the new site keeps every old page. It means no old address ever returns a 404 or a blank. Every row in the sheet gets exactly one of three decisions, written down before anyone builds a page.

Note the third row. "Cut" never means "let it 404." The page stops existing and the address keeps working — attachment page to the service page it illustrated, dead town post to the town page. A blanket redirect of everything to the homepage is the opposite of that: Google treats it as a soft 404 and the signal is gone.

Two rules hold on every migration. One hop — old URL straight to final URL, no chains through intermediate redirects, whatever the old .htaccess already had; flatten it at build time. And 301, not 302 — permanent means permanent, because a temporary redirect tells Google to keep the old address in the index and wait.

Plugin-generated schema on a long-running WordPress site is almost always a mess: duplicate entities, a LocalBusiness block fighting an Organization block, stale hours, a service-area list that never got updated when the business added three towns. Porting that across is porting the problem.

So we throw it out and write it fresh, hand-authored into the templates:

• One canonical business entity, one @id, referenced everywhere else instead of repeated
• Service pages that declare the actual service and the actual area served — for a wildlife or pest-control operator, that means named towns, not a radius nobody can verify
• Breadcrumbs matching the new URL structure exactly
• FAQ blocks only where a real FAQ exists on the page, never invented to farm a rich result

You can check that this is how we build. Open any page on thecritterguy.ca and view source: the structured data sits in the template, hand-written, with no plugin between it and the page. More on the specific markup in the schema a service business actually needs.

Every redirect is testable on a staging URL before DNS moves. There is no reason to discover a broken rule with live traffic on it.

1. Replay the full inventory. Every old path, requested against the new build, status code and final destination recorded.
2. Assert the shape. Each row is either 200 at its own address or 301 to a 200, in one hop. Anything else fails the run and gets fixed.
3. Spot-check the money pages by hand. Automation confirms the status code. A human confirms the destination is the right page.
4. Check the canonicals and the sitemap. The new sitemap contains only live, canonical, 200-status URLs — no redirected URLs, no noindex pages.
5. Re-run after every build. The map is code, so it belongs in the build and gets re-tested on every push rather than trusted once.

replay: every inventoried URL → asserted
allowed: 200 at self, or 301 → 200 in one hop
fail:    any 404, any 302, any chain, any homepage catch-all
→ cutover gate

Flip day is deliberately boring, because everything interesting happened in testing.

• DNS TTL lowered a day ahead so the flip propagates fast and rolls back faster
• New sitemap submitted in Search Console the moment the new site is authoritative; the old sitemap left reachable briefly, because it is a list of addresses you want Google to re-request and see 301
• Robots.txt checked first, before anything else. A staging Disallow: / shipped to production is the most expensive typo in this business.
• Analytics and form delivery confirmed with a real test submission, not a hopeful assumption
• The inventory replay run once more against the live domain

One thing at cutover gets undersold: the CMS attack surface disappears. No database, no plugins, no admin login to brute-force. We have rescued a business from a roughly 1,200-page spam infestation — cleaned it, rebuilt it, re-ranked it, and moved it to exactly this architecture, with nothing left to reinfect. We do not name clients in situations like that, and we would rather you judge us on that policy than on a logo wall. The method is in what to do when your WordPress site is hacked.

The technical work finishes on cutover day. The rankings do not move that day. Google has to re-crawl every old address, follow each 301, and re-evaluate the destination. That takes as long as it takes, and it is not uniform — the homepage gets re-crawled far sooner than a town page from 2018.

Some wobble in that window is normal. Positions move, impressions dip and recover, individual pages drop and come back. A steady, broad, sustained decline is a different thing, and it has a findable cause — usually a redirect rule, a noindex, or a canonical pointing at the wrong page.

Week one — is it mechanically correct?

• Crawl the live site end to end: zero unexpected 404s, zero chains.
• URL Inspection on your five most important pages. Live test each — indexable, correct canonical, schema detected.
• Sitemap read successfully, and forms tested from a phone, on cellular, by a human.

Week two — is Google processing the moves?

• Crawl stats: are old URLs being requested and receiving 301s?
• Are new URLs appearing as indexed while old equivalents move to "Page with redirect"? That transition is the signal you want.
• Compare queries, not just totals. If the same queries still surface the site, equity is transferring.

Month one — is it settling?

• Indexed-page count against the mirror list. Anything mirrored but unindexed gets investigated individually.
• Backlink report re-checked: are inbound links landing on 301s that resolve?
• Rich results report for the rebuilt schema — valid, and appearing.

If something genuinely went wrong, it is diagnosable rather than mysterious. The sequence is written up in traffic dropped after your website relaunch.

Because we do not have the export in hand, and we will not draw a line we cannot source. Every claim on this site is meant to be checkable in one click: the portfolio sites are live, so open thecritterguy.ca, run Lighthouse, view source, read the schema. That is a receipt. A chart with an arrow going up is not — you would have to take our word for it, and taking an agency's word for it is the habit that got the industry here. Anyone can render a percentage. Nobody can render a live site they did not build.

So this post is the mechanism, not the outcome. When a migration's own Search Console data is ours to publish, it gets appended here with the source named. The rest of the live work is on the case studies — open them and check the scores yourself.

One line, from our Websites page, and it is the whole commitment: We mirror what earns and cut what doesn't. Every existing URL is preserved or 301-redirected — giving the rankings you've built every reason to follow.

If you have a long-running site and the reason you have not moved it is fear of what happens to the rankings, that fear is reasonable and the answer to it is an inventory. Send us the domain and tell us what you want to rank for — you will get a real reply from the people who would do the work.