A re-platform is the moment a business is most likely to vanish from Google. Years of indexed URLs, backlinks, and rankings all point at an old site structure, and a new site that answers none of those addresses throws that history away. The damage rarely announces itself, either. Traffic just quietly sags for months.
So when Kwaan Bear Technology, an Alaska Native Corporation and SBA 8(a) certified federal IT contractor, brought us in to replace their WordPress site with a custom Next.js build, the redirect plan was not an afterthought at the end of the project. It was designed before the homepage was.
The stakes were concrete. Federal buyers and teaming partners find contractors by searching, and the old site had been accumulating that visibility for years. A clean cutover was not a nice-to-have. It was the difference between a new site that inherits an audience and one that starts from zero.
Every URL Google knows is an asset
The first job was an inventory. Not just the pages in the old menu, but every URL the old WordPress install had ever taught Google: page slugs like /about-us and /contact-us, six flat capability URLs that no longer matched the new site structure, blog posts whose slugs we renamed, and leftovers the old site was already redirecting itself, like /home and /index.php.
Each of those went into redirect middleware as an exact legacy-to-new mapping: 23 exact rules, one subtree rule, and a general trailing-slash cleanup. Every one issues a real HTTP 301, the permanent kind, which tells search engines to transfer the old URL's standing to the new address.
The mapping table is boring to build and impossible to skip. Redirect the homepage and the contact page and you have saved the URLs nobody was worried about. The equity lives in the long tail: the service pages, the old posts, the URLs other sites linked to years ago.
One hop, not two
Here is the detail most migrations miss. WordPress URLs often carry trailing slashes, and Next.js by default normalizes those with its own redirect before custom rules ever run. The result is a chain: a 308 to strip the slash, then a 301 to the new page. Two hops for every old link.
Redirect chains dilute the signal and slow the crawl, so we turned off the framework's automatic handling and did the normalization inside our own middleware. An old trailing-slash WordPress URL now gets exactly one clean 301, straight to its final destination. Query strings survive every redirect too, so tagged campaign links keep working.
It is a small configuration decision with an outsized payoff. Search engines follow chains, but each extra hop is friction: more requests to crawl the same content, more places for a link to break, and a weaker case that the move is permanent. One hop is a clean signal. Two is a shrug.
The sitemaps nobody remembers
A WordPress site running the Yoast SEO plugin publishes its own family of sitemap files: /sitemap_index.xml, /post-sitemap.xml, and friends. Google has been requesting those URLs for years, and it will keep requesting them long after the plugin is gone.
Most redirect setups never see those requests, because the routing layer is configured to skip anything that looks like a static file. We configured ours to deliberately let .xml paths through, then pointed all five legacy Yoast sitemap URLs at the new sitemap with 301s. When Google asks the old question, it gets a current answer.
- 23 exact legacy-to-new URL mappings, plus one subtree rule
- Trailing-slash cleanup that redirects in one hop, not two
- Five legacy Yoast sitemap XMLs pointed at the new sitemap
- Query strings preserved through every redirect
- Real HTTP 301s throughout, so the transfer reads as permanent
Verified live, not assumed
A redirect map you have not tested is a redirect map with bugs in it. Before calling the work done, we requested every legacy URL against the live deployment, 30 in all, and confirmed each one resolved in a single 301 hop to the right destination. Not a sample. All of them.
The new site holds up its end as well: metadata on every route, a typed sitemap with real last-modified dates, and Organization structured data so search engines understand who the company is, not just what the pages say. The whole thing runs on four runtime dependencies, which is its own kind of insurance.
The takeaway
Re-platforming does not have to mean starting over with Google. It means treating every old URL as an obligation, engineering the handoff at the framework level so each one transfers in a single permanent hop, and then verifying the result against the live site instead of trusting the config.
None of this is specific to WordPress or to federal contractors. Any business with years of history on a rented platform can move to code it owns without dropping the search standing it paid for. But only if someone does the unglamorous work of counting the URLs first.
