Can Fetch as Google really detect invisible cloaking hacks?

Why do some hacks remain invisible in a standard browser?

Hackers often use cloaking techniques to hide their modifications. The idea is to detect Googlebot's user-agent and serve different content than what is displayed to human visitors.

The result? You browse your site using Chrome or Firefox and everything appears normal. Meanwhile, Googlebot indexes pages filled with spam links, redirects to pharmacies, or malicious duplicate content. The hack remains invisible until Google penalizes the site for manipulation.

What is Fetch as Google and what is it really used for?

Fetch as Google was the former name of what is now known as the URL inspection tool in Google Search Console. It enables you to see exactly what Googlebot retrieves when crawling a page.

The tool displays the raw HTML code sent to the bot, JavaScript rendering, blocked resources, and potential errors. It is your only way to check if the server serves the same version to Google as it does to regular users. For a compromised site, the difference is glaring: modified meta tags, injected scripts, hidden footer links.

In what context does Google recommend this tool?

Eric Kuan specifically mentions the review process, meaning after a site has been penalized or flagged as compromised. Google requests a reconsideration request after the issue has been fixed.

Before submitting this request, you need to prove that the hack has been eradicated. Visually checking the site is not enough: persistent cloaking can continue polluting the index. Using the inspection tool is then a critical validation step before re-examination.

• Cloaking: a technique to serve different content depending on the visitor's user-agent
• URL inspection tool (formerly Fetch as Google): allows you to see exactly what Googlebot retrieves from the server
• Security review: the process of lifting a penalty after fixing a hack or manipulation
• Hidden injection: malicious code invisible in the browser but present in the HTML served to the bot
• Server-side validation: essential to ensure that the HTML content sent to Google is clean

Is this recommendation still relevant with the current tool?

Yes, even though Fetch as Google no longer exists under that name. The URL inspection tool in the Search Console serves exactly the same function, with an improved interface. The logic remains the same: compare Googlebot's rendering to user rendering.

Eric Kuan's statement retains its relevance. Cloaking hacks have not disappeared; they have even become more sophisticated. Some scripts now check for multiple simultaneous signals (IP, user-agent, referrer, geolocation) to better mask the injection. The inspection tool remains the first line of defense, but sometimes you need to go further with tests from different IPs and user-agents.

What limitations should you keep in mind with this tool?

The inspection tool shows what Google sees at the time of testing, not necessarily what was crawled and indexed before. A hack could have been active for weeks before detection, massively polluting the index.

Another limitation: some advanced cloaking techniques detect requests from the Search Console and temporarily go dormant. This is rare, but has been observed in persistent infections. In such cases, you need to cross-check with raw server logs, a Screaming Frog crawl with different user-agents, or even a forensic audit if the site has significant business stakes. [To be verified]: Google has never publicly communicated about hackers' ability to detect GSC inspection requests, but anecdotal cases exist.

How can you differentiate a false alert from a real cloaking problem?

Not every discrepancy between user rendering and Googlebot rendering signals a hack. Sites with heavy JavaScript often exhibit legitimate differences: AJAX-loaded content, lazy loading, CSS animations disabled for the bot.

The real red flag: the presence of unexpected textual content (links to pharmacies, keywords unrelated to your topic), 301/302 redirects not configured by you, meta title/description tags altered without your knowledge. If the tool reveals elements you have never implemented, it is a hack. If it is just a CSS/JS rendering difference, that is normal.

What should you do concretely after a suspected hack?

First step: audit all sensitive pages using the URL inspection tool. Start with the homepage, then the main categories, and high traffic product pages. Hackers often inject their code into the most crawled templates to maximize SEO impact.

Systematically compare the rendered HTML code with the source code of your templates. Look for hidden iframes, illegitimate external scripts, blocks of links in display:none. If you find anomalies, do not simply delete them manually: identify the infection vector (outdated WordPress plugin, compromised FTP, SQL injection), or the hack will return in 48 hours.

How can you verify that a cleanup is genuinely complete?

After correction, wait 24-48 hours and re-run the inspection tool on a representative sample of pages. Also check Google's cached URLs (cache:yourwebsite.com/page) to detect any indexed residues.

Consult server logs to spot unusual Googlebot requests: URLs never created, unusual crawl patterns, unexplained bandwidth spikes. A hack can generate thousands of phantom pages that you do not see in your CMS but that Google has indexed. Cross-reference this data with a Site: export in the Search Console to list all indexed URLs.

What mistakes should you avoid during a security reexamination?

Classic mistake: submitting a reconsideration request too quickly, before eradicating all traces. Google will reject the request and you will waste time. It's better to spend 2-3 days checking every nook and cranny than to rush and have to start over.

Another pitfall: only cleaning the visible pages while neglecting backups, old file versions (.php.bak, .old), temporary directories. Hackers often leave backdoors in these locations. If you do not delete them, the hack will reactivate post-reexamination. Finally, never forget to change all passwords (FTP, SSH, CMS admin, database) after a confirmed hack.

• Run the URL inspection tool on the homepage, categories, and top traffic pages
• Compare the HTML rendered by Googlebot with the source code of your templates
• Check server logs for ghost URLs crawled by Google
• Export the complete list of indexed URLs via Site: in GSC
• Delete all suspicious backups and temporary files from the server
• Change all access credentials (FTP, admin, database)