Why Changing Your CMS Broke Links You Never Touched

A platform migration can change URLs nobody meant to change. Trailing slashes, default permalink patterns and character encoding can differ between content management systems, so a migration that “kept the same structure” can still alter every address on the site, and links to the old addresses start returning 404. A second failure hides behind the first: a redirect plugin that shows its rules as active is reporting its own settings, not what the server returns. Recovery means rebuilding as complete a list of old URLs as you can, mapping each one to its real new address, putting the redirects where they run first, and verifying each one by its actual response.

How “preserved” URLs change

Trailing slashes. Google’s post on trailing slashes says Google treats a URL with a trailing slash and one without it separately. If the old platform served /pricing and the new one serves /pricing/, every link to the old form points at a different URL, even though the slug looks the same.

Default patterns. Each platform builds addresses its own way. One CMS may expose a numeric system path alongside the friendly alias; another builds permalinks from a configurable pattern that can add a category or date segment. Unless the old pattern is reproduced on purpose, the new addresses can come out structurally different.

Encoding. Spaces, accented letters and punctuation in slugs can be encoded differently by the new system, producing URLs that look the same to a person and differ to a server.

Why an “active” redirect can still 404

A request for an old URL can pass through a CDN, then the web server, then the CMS. The first layer that answers wins. If the web server resolves the path first, for example with a rewrite rule or a 404 for a path with no file behind it, the request never reaches the CMS and the plugin’s rule never runs. A caching layer can do the same by serving a stored 404. A plugin conflict can stop the rule from loading at all. In each case the plugin screen says “active” and the live URL says “not found.”

That is why the layer matters. Google’s documentation on redirects describes server-side redirects as set in the server configuration files, such as .htaccess on Apache, or through redirect headers from server-side scripts, and recommends a permanent server-side redirect whenever possible. Rules in the web server or CDN configuration answer before the CMS loads. If a plugin is your only option, treat its rules as unverified until each one passes a live check.

Rebuild the list of old URLs

You can’t redirect URLs you don’t know about. Google’s site move guide lists where to find old URLs, starting with the important ones:

• the sitemaps you submitted
• server logs or analytics, for the URLs that get the most traffic
• the Links report in Search Console, for pages with internal and external links
• your old CMS, if you still have access to it, which can list every URL that hosts content

It also says to check server logs for URLs visited at least once recently, over a period that accounts for seasonal traffic, and to include embedded files: images, videos, JavaScript and CSS.

Search Console’s reports help, but they aren’t an inventory. The Page indexing report help says the list of example URLs is limited to 1,000 items and isn’t guaranteed to show all URLs in a given status. Use it to find patterns, not to build the complete list.

Map, redirect, verify

1. Map each old URL to its real counterpart. Where there is no exact match, choose the closest relevant page. The site move guide warns against redirecting many old URLs to one irrelevant destination such as the home page, which can confuse users and might be treated as a soft 404.
2. Implement at the earliest reliable layer. Use the web server configuration, or the CDN’s redirect rules if your host blocks server configuration. Use a permanent status for permanent moves.
3. Verify by response, not by settings. Request a sample of old URLs from each section in a private window with the browser’s network panel open, and read the status: a 301 with the right Location is working, a 404 is broken, a 500 is a server error. Then check the whole list with a crawler in list mode, so you see which URL patterns redirect cleanly and which don’t. Confirm the targets return 200, not another redirect or a 404.

Work in order of value: rank the old URLs by traffic and outside links, highest first.

What recovery looks like

The links on other sites still point at your old URLs. Once each old URL returns a permanent redirect, those links lead to the new page, and Google’s redirects documentation says the indexing pipeline uses a permanent redirect as a signal that the target should be canonical. You don’t have to earn the links again; you have to make the redirects answer.

Recovery then waits on recrawling. Update internal links to the new URLs so your own site doesn’t depend on the redirects, and keep the redirect list in the server or CDN configuration, where a future CMS change won’t take it down with the plugin.

Frequently asked questions

My redirect plugin says all rules are active. Why do old URLs still 404?

The plugin reports its own settings, not the server’s response. The web server, a cache or a plugin conflict can answer the request before the rule runs. Request the old URL in a private window with the network panel open and read the real status code.

Can I export my old URLs from Search Console?

Partly. The Page indexing report’s example lists are limited to 1,000 URLs and aren’t guaranteed to be complete. Combine them with sitemaps, server logs, analytics, the Links report and a listing from the old CMS.

Should I redirect everything to the home page to clear the 404s?

No. Google’s site move guide says that redirecting many old URLs to an irrelevant page such as the home page can confuse users and might be treated as a soft 404. Map each URL to its real counterpart.