An agency-exit indexing incident: the historical lesson

In 2015, we reported finding code on a new client’s WordPress site that fetched content from a remote address and inserted it into the page head. The fetched content included a noindex directive.

The original account said the team traced the behaviour to a function in the theme code. The former provider’s domain was withheld. That mechanism, rather than the identity of the provider, is the useful lesson to retain.

Check what the site actually sends

An indexing directive can come from a theme, plugin, server configuration or another dependency. Checking a CMS settings screen alone may not explain the public response. Inspect the page HTML and HTTP headers, then trace the source of any unexpected instruction.

The presence of noindex is not proof of malicious intent. A migration mistake or a development setting can produce the same symptom. Preserve evidence and diagnose the cause before attributing responsibility.

Make the handover testable

When changing suppliers, record who controls hosting, DNS, deployments and external services. Review outgoing access and remote dependencies. Verify important pages and the enquiry or purchase flow before and after the handover.

If search visibility changes, use the deindexing diagnosis guide rather than assuming every traffic drop has the same cause. The hosting checklist covers business ownership and recovery access.

Historical note: this is an edited account of the original 2015 report, not a current allegation about an identifiable provider. The original URL and publication date are preserved. No executable code from the incident is reproduced.