Member Avatar for techniner

OK people I need to know how many people are getting this...

Recreate this error by going to google then type:

inurl:somedomain.com

Then click like PAGE 2 down at the bottom.

You should be presented with this fine message:

We're sorry...

... but we can't process your request right now. A computer virus or spyware application is sending us automated requests, and it appears that your computer or network has been infected.

We'll restore your access as quickly as possible, so try again soon. In the meantime, you might want to run a virus checker or spyware remover to make sure that your computer is free of viruses and other spurious software.

We apologize for the inconvenience, and hope we'll see you again on Google.

Not sure if its my net but i know 100% its not the PC and I have tried it from a few different IPS and hosts and same results.. all using different domains.

So whats everyones thoughts on this?

  • 2 Contributors
  • 2 Replies
  • 324 Views
  • 9 Hours Discussion Span
  • Latest Post Latest Post by techniner

Dani AI

Generated

Short expert note tied to this thread (Aug 2005): the behavior reported by and noted by — a Google response claiming "automated requests" when using advanced operators and paging — is consistent with server-side automated-query detection and temporary rate-limiting. Because already tried different ISPs and hosts, a single infected PC becomes less likely; the pattern instead points toward either a flagged public IP range, an automated-query pattern that triggered Google, or an active background process on the network.

Practical diagnostic checklist:

  • Isolate origin: repeat the same search from a known-clean machine and from an unrelated network (cellular tether or public Wi‑Fi). If the block follows the public IP but not the cellular link, the IP or provider range is the likely target.
  • Scan for local automation or malware: inspect running processes, browser toolbars/extensions, and scheduled jobs; run up-to-date anti-malware tools.
  • Audit network services: check for open proxies, shared NATs, or hosted/VPS ranges that other machines may be using; hosting providers or university NATs can inherit blocks.
  • Reduce automated footprint: pause link-checkers, crawlers, or SEO tools and retry after a pause; excessive repeated advanced-operator queries or deep paging is a common trigger.

Quick technical check (capture response headers):

curl -I "https://www.google.com/search?q=inurl:example.com&start=10" -A "Mozilla/5.0"

Save timestamps and response headers for any blocked responses; these are useful when escalating.

Mitigation and context: spacing requests, adding exponential backoff, and using official APIs or slower, randomized checks reduces risk of being flagged. If the block persists across multiple, clean networks and times, collect evidence (timestamps, headers, public IPs) and escalate through the ISP or Google support channels. Note that search-defence behavior and CAPTCHAs have evolved since 2005; the diagnostic steps above remain the most practical way to distinguish local infection from provider-side or query-pattern rate-limiting.

Recommended Answers

All 2 Replies

Member Avatar for jewboy

Yes, this is very strange indeed. Never saw a message like that before.

Member Avatar for techniner

I can't see how or why they would do this.

My only thoughts are to stop like bots or peoples scripts form doing link pop checks etc etc..

But i think that is really not fair.

How can one gauge each other if one is working in the dark?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.