The call usually starts the same way. Someone at a treatment center searches for their own program, and the result under their name shows a title about discount pharmaceuticals, casino bonuses or replica handbags. They click through and the site looks perfectly normal. The clinical director checks from her phone and it looks normal too. Nobody on staff can reproduce what Google is showing, so the problem gets filed as “a Google glitch” and left alone for weeks.
It is almost never a glitch. It is hacked content that was built specifically so the people who run the site would not see it. This post explains how that concealment works, what Google’s Security Issues report actually tells you, and why the cleanup order matters more than the cleanup speed, including one rule that can lock you out of requesting a review for 30 days.
Why the people who own the site can’t see the hack
Google’s spam policies for Google web search define hacked content as anything placed on a site without permission because of a security vulnerability, and they describe four forms it usually takes. Each one is designed to be visible to a search engine or a stranger, and easy to miss for someone who visits the site every day.
- Code injection: malicious JavaScript or an iframe is inserted into existing pages, often into a theme file or a database field that loads on every page.
- Page injection: entirely new spam pages are created on your domain, usually in a directory nobody on your team ever opens, so your real pages show no sign of a problem.
- Content injection: links or text are added to your real pages but hidden with CSS or HTML, or served only to crawlers through cloaking.
- Conditional redirects: code sends some visitors to a spam or harmful page based on the referrer, user agent or device, so a click from Google Search redirects while typing the URL directly does not.
That last one is the reason the clinical director could not reproduce the problem. Google’s own example in that policy is exactly this: a URL clicked from search results redirects to a suspicious page, but the same URL visited directly does not. Staff tend to reach their own site by typing the address or using a bookmark, and some injected scripts also skip visitors who are logged in to WordPress. The hack is aimed away from the one audience that would complain.
What the Security Issues report shows, and what it doesn’t
Search Console’s Security Issues report is where Google records a determination that your site was hacked or is behaving in a way that could harm visitors. It groups findings into three categories: hacked content, malware and unwanted software, and social engineering. Affected pages can carry a warning label in search results, or trigger a full-page browser warning before anyone reaches your admissions phone number.
Three details in that documentation change how a cleanup should be run:
- The sample list is not the full list: Google says the example URLs are only a sample, and that a security issue can appear with no example URLs at all without meaning that no pages are affected.
- Partial fixes earn nothing: Google states that fixing an issue on only some pages will not earn a partial return to search results, and that every listed issue must be fixed before you request review.
- The report outranks your own testing: because Safe Browsing warnings depend on browsing context, Google tells site owners to treat the report as the source of truth for whether an issue exists or has been fixed, not their own attempts to reproduce it.
The report is also separate from the Manual Actions report. Manual actions cover attempts to manipulate the index and usually show up as ranking loss with no visible warning. Security issues are about potential harm to visitors and are the ones that put a warning in front of a prospective patient.
The 30-day rule that makes rushing expensive
Under Google’s Safe Browsing Repeat Offenders policy, a website that switches between compliant and noncompliant behavior within a short window of time can be classified as a Repeat Offender. Once that happens, the site owner can no longer request reviews through Search Console, and the Repeat Offender status persists for 30 days before a review can be requested again. A treatment center website that is cleaned, approved and then reinfected through the same unpatched plugin can spend a month with its warning in place and no way to ask Google to look again.
That rule, documented in the Safe Browsing Repeat Offenders policy, is the inconvenient operational truth behind most failed cleanups. The pressure on a treatment center is to get the warning off fast, because admissions calls drop while it is up. The fastest-looking path is to delete the visible spam pages and click Request Review the same afternoon. If the entry point (an outdated plugin, a reused admin password, a forgotten staging copy on the same server) is still open, the spam tends to come back, and the next round is the one that risks the lockout. Google’s Security Issues documentation adds that submitting a request before the issue is fixed can lengthen the turnaround for the next one, and that most reviews take several days or weeks.
A cleanup order that holds
The sequence below follows Google’s documented requirements and is the order we use in WordPress remediation work. The point is to close the door before you sweep the floor.
- Confirm scope from Google’s side, not yours. Open the Security Issues report and Manual Actions report in Search Console. Then run the URL Inspection tool’s live test on a few affected URLs and view the tested page, which shows what Google’s crawler received rather than what your browser shows you.
- Find the entry point. Review WordPress users for administrator accounts nobody recognizes, update or remove abandoned plugins and themes, rotate every admin, hosting, FTP and database password, and check for old staging or development copies on the same hosting account.
- Remove the injected content everywhere. That includes spam directories, modified theme files, the must-use plugins folder (easy to miss because those plugins can’t be deactivated from the normal plugin screen), server rewrite rules that redirect based on referrer, and database entries. Restoring a backup works only if you know the backup predates the compromise.
- Make spam URLs return the right status. Removed spam pages should return 404 or 410. Don’t block them in robots.txt, which stops Google from recrawling them and seeing that they’re gone. We covered why in robots.txt vs. noindex. The Removals tool can hide spam URLs temporarily, but it does not remove them from the index permanently.
- Request review once, with specifics. Google asks that a review request explain the exact issue, describe the steps taken, and document the outcome. Then wait for the decision email before submitting anything else.
A check you can run today
You don’t need to wait for a warning to find out. Paste this into Google, replacing the domain with yours:
site:yourdomain.com casino OR viagra OR cialis OR replica OR "payday loan"
Then open Search Console, go to the Performance report, and sort the Queries table by impressions. Any query in a language your site doesn’t publish in, or for products you have never offered, is worth investigating. Finally, compare the number of indexed pages in the Page Indexing report against the number of pages you know you have. A small practice website that reports thousands of indexed URLs has pages on it that nobody on staff wrote.
None of these checks prove a site is clean. They are an early warning, and they are good at catching injected spam pages before Google labels the site.
The HIPAA question a hack raises
For most businesses a hacked website is a search and reputation problem. For a treatment provider it can also be a privacy problem. If the compromised site hosts an intake form, a verification-of-benefits form or a contact form that collects information about someone’s treatment, injected code may have been able to read what visitors typed. Whether that counts as a reportable breach depends on what was collected, how forms were processed and stored, and what the forensic review shows, which is a determination for your privacy officer and counsel, not your web vendor.
The timeline matters regardless. Under the HIPAA Breach Notification Rule, covered entities must notify affected individuals without unreasonable delay and no later than 60 calendar days after discovering a breach of unsecured protected health information. That clock is one more reason a “Google glitch” should be investigated the week it is noticed, and why form handling deserves attention in any treatment center web design project before anything goes wrong.
Prevention is mostly maintenance
Nothing about preventing this is exotic. The sites that get reinfected are the ones where plugin updates wait for a redesign, admin accounts are shared between staff and former vendors, and nobody owns Search Console. The sites that recover quickly are the ones where someone is already verified in Search Console, gets the email when the Security Issues report changes, and knows which plugins are installed and why.
If your search listing has ever shown something your team didn’t write, treat it as a security finding first and a ranking problem second. If you want a second set of eyes on what Google is seeing for your domain, our SEO services start with exactly that audit.
