Moving a Sports Site Off WordPress Without Losing Search Traffic

We moved redlabelsports.com off a traditional WordPress site and onto a custom front end, with WordPress kept behind the scenes as a headless CMS. The new site is faster and easier to build on. The migration also introduced a set of search problems that were invisible in a browser and obvious to a crawler.

This is a write-up of those problems and how we fixed each one. If you run a sports site with years of articles and you are planning a rebuild, treat it as a checklist.

The setup

The old site was standard WordPress: articles lived at the root of the domain, at addresses like /ncaa-nil-rules-guide/, with tag, author, and category archives around them.

The new site is a React application. WordPress moved to a subdomain and now only serves content through its API. At build time, every page is rendered to static HTML, so a crawler receives the full article without running JavaScript. Articles moved under a /news/ prefix.

That architecture is sound. The problems were all in the details of the move.

1. Old article addresses led nowhere

Every article's address changed from /article-name/ to /news/article-name. Nothing connected the two. Any link that another site had built to an article over the years, and any result still in a search index, now pointed at a page that no longer existed.

The fix: a permanent (301) redirect from every old address to its new one, plus redirects from the old tag, author, and category archives to the news index. We built the list from two sources: the CMS itself, and the Wayback Machine's record of which addresses had actually been live.

The check: before launch, export every URL the old site served. After launch, request each one and confirm it returns a redirect to the right page. This is the single most valuable step in a migration, and the easiest to skip.

2. Missing pages answered "200 OK"

The new site was a single-page application, configured so that any unknown address served the application shell. That is a common setup. It also meant that a request for a page that did not exist returned the home page with a success status.

To a search engine, that is a soft 404: thousands of possible addresses that all return the same content and all claim to be real pages. It wastes crawl budget and muddies the signal about which pages matter.

The fix: unknown addresses now return a real 404 status with a useful not-found page. Only the routes that genuinely need the application shell still receive it.

The check: request an address you know is nonsense and look at the status code, not the page.

3. The article index had no links in it

The news index fetched its list of articles in the browser after the page loaded. The static HTML that a crawler received said "Loading the latest posts" and contained no links to any article.

The articles were in the sitemap, so they could be discovered. But internal links are how search engines judge which pages a site considers important, and the site was not linking to its own archive.

The fix: the index is now rendered at build time with the article list in the HTML, and it links to every article, not only the newest six.

The check: view the page source, not the inspector. If the links are not in the source, do not count on them.

4. Only the newest articles were prerendered

The build rendered the 50 most recent articles to static pages. The archive had 72. The other 22 fell through to the application shell, which, because of problem 2, was the home page with the home page's canonical tag.

The fix: the build now pages through the whole archive.

The check: compare the number of URLs in your sitemap with the number of published articles in your CMS. They should match.

5. Articles linked to the CMS, not the site

Article bodies were full of links to other articles. Those links had been rewritten along with the WordPress move, so they pointed at the CMS subdomain, which is correctly set to noindex. Readers who clicked them left the site for a bare WordPress theme, and the link value went with them.

The fix: links to the CMS host are rewritten to the matching page on the main site when each article is loaded.

The check: search your rendered article HTML for the CMS hostname. The only matches should be media files.

6. The www address was broken

The domain's www address pointed at the new host but had never been attached to the project, so it failed with a certificate error. Anyone who typed www, or followed an old link that used it, saw a browser warning.

The fix: attach the www host and redirect it permanently to the bare domain.

The check: test all four combinations of http, https, www, and bare domain. Three should redirect to the fourth.

7. Images and embeds needed a second pass

Two smaller problems came from old content meeting a new front end. Some images were hosted on a service that had since been retired, leaving broken image icons. And every embedded video loaded a full video player, whether or not anyone pressed play.

The fix: images that fail to load are removed from the page, and video embeds are replaced with a lightweight thumbnail that loads the player on click.

The migration checklist

1. Export every URL the old site serves, including archives and feeds.
2. Map each old URL to a new one. Redirect with a 301.
3. Return a real 404 for addresses that do not exist.
4. Confirm article pages and index pages contain their content and links in the HTML source.
5. Confirm the sitemap count matches the CMS count.
6. Search rendered pages for the old or internal hostname.
7. Noindex the CMS host, and nothing else.
8. Test http, https, www, and bare-domain variants.
9. Check images and embeds on your oldest articles, not your newest.
10. Re-run the whole list a week after launch, then on a schedule.

The last item matters most. None of these problems caused an error anyone would notice while browsing the site. We now run an automated audit against the live site every week that checks each item above, because a migration is finished when the checks keep passing, not when the new site goes live.

Migrations like this are part of our platform engineering work. If you are planning one for a sports site or network, we are glad to talk it through.