Practical security advice for website owners
Still Redirecting After WordPress Cleanup? Check Every Cache Layer
Security guidance · References checked 2 November 2026
In this guide
You have been told the website was cleaned, but a visitor still sees the old redirect. That may mean active malicious behaviour remains. It may also mean an old response is being served by a cache, an edge redirect rule or a browser state that the cleanup did not address.
Do not declare either reinfection or success before locating the response. A useful verification process identifies where the redirect originates, compares controlled requests and records the limits of each test.
Capture a reproducible observation
Record the starting URL, final destination, time, device and the steps that led there. Note whether the visit began from a search result, a bookmark or a direct URL. Avoid opening an unsafe destination repeatedly; a responder can inspect the redirect chain in a controlled environment.
Ask whether it affects logged-out visitors, mobile devices, particular paths or only one browser. Conditional behaviour can matter, but a difference is not proof of an attacker’s intent. Capture it as an observation and test a small, authorised set of relevant conditions.
Preserve the earlier cleanup scope and report. If the original work covered only one component, the remaining symptom may be outside that scope. Establish what was actually investigated before assuming that a whole-site recovery was completed.
Identify the redirect layer
A redirect can be produced by the web server, WordPress, an extension, edge configuration or browser-side code. The appropriate investigation follows the observed response. A database search alone will not reveal an edge rule managed in a separate account.
Have an authorised developer examine the HTTP response and relevant page behaviour. Record the requested hostname and the layer being tested. Avoid publishing private origin addresses or weakening access controls merely to obtain a convenient test route.
For caching behaviour, the MDN HTTP caching guide explains the general roles of caches and response controls. Your actual hosting and CDN configuration determines what is stored and how it is invalidated.
Inventory the caches in use
List the browser cache, WordPress page-cache plugin, hosting cache, CDN and any other relevant application or reverse-proxy layer. Ask the host which purge actions clear which layers. A button labelled “clear cache” may operate on only one of them.
Also inspect redirect rules separately from cached content. Purging a cached response does not remove a permanent configuration rule that will generate it again. Likewise, replacing a plugin file does not change an unrelated edge rule.
Do not install a second cache plugin as a diagnostic shortcut. It adds another variable and can make request behaviour harder to interpret. Start with the tools and layers already configured, and document any temporary bypass.
Verify the origin state through an approved route
The responder should determine whether the current application or server still emits the unwanted behaviour. Use a safe, authorised method coordinated with hosting; do not expose an origin that was intentionally protected or bypass authentication in production.
A random query parameter is not a universal cache bypass. Cache keys and rules differ, and some configurations ignore query strings. Read the response evidence and provider documentation instead of assuming a URL variation proves you reached fresh origin content.
If the origin still produces the redirect, continue the incident investigation. If it does not, review the relevant downstream cache or rule. Both findings should be expressed with their tested scope, not as a claim about every visitor everywhere.
Purge deliberately after the correction
Once the source is corrected, invalidate the affected cached responses using supported controls. Cloudflare documents its available cache-purge methods. Other providers have different features and limits, so use the instructions for the service actually deployed.
Choose a targeted purge where appropriate and account for related paths or cache variants. A full purge may increase origin load; discuss that trade-off for a busy site. Record the action and time so later tests can be interpreted correctly.
For browser state, use a fresh profile or controlled clean session for verification rather than telling every customer to erase their entire browsing history. If a service worker is part of the site, have its owner review its cache and update behaviour too.
Test both affected and business-critical paths
Recheck the original symptom with the same relevant conditions, then a clean session and appropriate device sizes. Confirm that the redirect no longer appears in the tested responses and that legitimate redirects still work.
Test contact forms, account pages and store checkout in supported test mode where relevant. A broad cache or redirect change can inadvertently cache personal content, break a callback or disrupt a canonical URL. Successful removal of one symptom is not the only acceptance criterion.
Observe over an agreed period if the original behaviour was intermittent. A single successful request is useful evidence but cannot guarantee that no conditional issue remains. State the test coverage and any conditions you could not reproduce.
Close with a clear distinction
A good report says whether the remaining behaviour came from active code, stored content, an edge rule or a cached response, and what evidence supports that conclusion. If the cause could not be fully established, make that limitation visible.
For recovery help, send the public starting URL, observed destination and approximate time. Do not include passwords or private origin details in an initial form. Ask for a response-path investigation rather than repeated generic scans or an unsupported promise that “it is only cache”.
Published by NithuDev. About Nithu / Suthakaran Nithursan, website developer and security recovery specialist. Featured artwork is an AI-generated editorial illustration, not a photograph of a client, a real security incident or a verified tool result.