Old CMS paths keep appearing because clients, crawlers, links, caches, or integrations continue requesting URLs that existed before the migration. A migration changes the website, but it does not erase old addresses from external systems or visitor devices. A log entry records a request, not proof that the old CMS remains installed. The response status, request source, and destination reveal whether the request is harmless, misdirected, or evidence of unfinished migration work.
Official resources:
- Follow Google’s URL migration and redirect guidance — Verify how long old URLs may be crawled and how to map, redirect, and retire legacy paths correctly.
- Configure permanent redirects for moved CMS URLs — Confirm which redirect behavior Google recognizes when old CMS paths have relevant replacement pages.
Table of Contents
- Where are the old requests coming from?
- What does the response code tell you?
- How can you identify the real source?
- Which requests should you fix first?
- When is it safe to leave the requests alone?
- A practical cleanup sequence
Where are the old requests coming from?
Search crawlers and automated scanners may revisit known URLs for months or probe common cms locations. Requests for paths such as `/wp-admin/`, `/user/login`, or `/sites/default/files/` can occur even if the site never used that platform. Real visitors may arrive through saved bookmarks, browser history, old emails, shared documents, or links on other websites.
Cached pages can also reference retired scripts, images, feeds, and stylesheets. Some requests originate inside your own systems. Common sources include:.
- Navigation links and image URLs copied into migrated content
- Old XML sitemaps, feeds, canonicals, or structured data
- Advertising destinations and campaign templates
- Scheduled jobs, monitoring tools, webhooks, and mobile apps
- CDN, proxy, browser, or service-worker caches
What does the response code tell you?
Start with the HTTP status code. A `301` or `308` means the server permanently redirects the old path. This is usually appropriate when a clear replacement exists. A `404` means no resource was found, while `410` explicitly says the resource is gone.
Either may be correct when retired content has no useful replacement. Redirecting every missing URL to the homepage can confuse visitors and conceal broken links. A `200` deserves closer inspection. It may mean the old path still serves content, a fallback page returns the wrong status, or the new application catches every route. A `500` indicates server-side failure and should receive priority because repeated requests may waste resources or expose a faulty compatibility layer.
How can you identify the real source?
Group requests by path, status, timestamp, user agent, referrer, and client address. Patterns are more useful than isolated entries. A recognizable referrer often points to a page containing an old link. A browser-like user agent combined with varied addresses may indicate real visitors. High-volume requests across familiar administrative paths often suggest automated scanning, although user-agent text can be forged.
Test important URLs without relying only on browser behavior. Browsers and intermediary caches may remember redirects. Confirm the complete redirect chain and verify that each old URL reaches the closest relevant destination in one step. Also crawl the current site and search exported content, templates, configuration files, sitemaps, and tag-manager settings for old path patterns. This separates external demand from errors still generated by the migrated site.
Which requests should you fix first?
Prioritize old URLs that receive meaningful traffic, have external links, appear in current campaigns, or represent valuable content. Map each one to the most relevant new page. Fix internal references before chasing every external request.
They are under your control and can create repeated traffic whenever a page loads. Update integrations and campaign destinations at their source instead of depending permanently on redirects. Treat these patterns as warning signs:.
When is it safe to leave the requests alone?
Occasional requests for generic CMS login pages usually need no migration work if the server returns a suitable `404`, `410`, or access-denied response. Blocking abusive clients may reduce load, but addresses and identifiers change easily. Do not recreate an old administrative endpoint merely to stop log noise. That expands the attack surface without helping visitors.
Keep the replacement platform patched, restrict sensitive routes, and rate-limit repeated abusive requests where appropriate. Retain redirects while they serve visitors or important external links. There is no universal expiration date. Low-value probes can remain unanswered, while heavily used legacy URLs may justify long-term redirects.
A practical cleanup sequence
Use a measured cleanup process rather than trying to eliminate every old-path entry: Expect some old requests to continue. The useful target is correct handling: one-step redirects for replaced content, honest missing-page responses for removed content, and no current system generating obsolete URLs.
- Export a representative log period and rank legacy paths by request count
- Separate real content URLs from generic scans and exploit attempts
- Check response codes and redirect chains for the highest-volume paths
- Repair current pages, templates, feeds, campaigns, and integrations
- Add one-to-one permanent redirects where a genuine replacement exists
You Might Also Like
- What Is New With CMS Migration and Web Development in August 2026? Latest release notes and search documentation and Key Takeaways
- How to Verify CMS Migration and Web Development Claims in 2026: release notes and search documentation, Evidence, and Red Flags
- How CMS Fingerprinting Bots Guess Which Software a Website Uses
