Indeed scraper agent hit a 48-hour IP ban - no proxy rotation and the datacenter IP got flagged mid-sourcing
Handles an Indeed IP ban after a scraper with no proxy rotation got a datacenter IP flagged mid-sourcing. Use when Indeed starts blocking all requests from the sourcing server for about 48 hours. Key trigger: every request denied right after a high-volume scrape from one datacenter IP.
TL;DR: Wait out the 48-hour ban and do not rotate proxies or IPs to get around it. Dodging the ban breaks the platform's rules and the next IP gets banned too. Move job and candidate data pulls to Indeed's official APIs or an ATS integration, and treat the ban as the signal to stop scraping.
Indeed scraper agent hit a 48-hour IP ban - no proxy rotation and the datacenter IP got flagged mid-sourcing- Stop all Indeed requests from the flagged IP immediately. Expected: request volume to Indeed drops to zero.
- Confirm the ban shape: make one manual request and note the block page or error. Expected: a clear access-denied response, not a bug in the scraper code.
- Wait the full 48 hours with no requests from that IP. Expected: access returns on its own after the window.
- Before any future pulls, switch to the official route for the data needed. Expected: the agent's next data pull runs through an approved integration with no blocks.
Use this when
- Indeed blocks a sourcing server's IP for roughly 48 hours
- The scrape ran at high volume from a single datacenter IP
- You need the same job or candidate data without risking another ban
Not for this skill when
- The block is a CAPTCHA or challenge page rather than an IP ban (different problem)
- You want proxy setups to keep scraping through the ban (do not do this)
- The errors are 404s or empty results, which point to a code bug, not a ban
Variant phrasings
Indeed blocked our IP for 48 hours during sourcing scrape
Indeed IP ban on datacenter IP from scraper
Indeed access denied after high volume scraping
Why it happens
Job boards fingerprint request patterns, and sustained high-volume traffic from a datacenter IP range with no human characteristics is trivially detectable. The 48-hour ban is the standard first response. Rotating IPs to continue is exactly the evasion the ban is meant to stop, so it escalates the enforcement.
Edge cases
- Shared infrastructure where other tenants also scrape: the IP may get banned for someone else's traffic, so move off shared egress for anything legitimate
- The ban not lifting after 48 hours: keep waiting and check from a different network before assuming it is permanent
- Legitimate use cases like salary research: use Indeed's official data products instead of scraping
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_oBEl-kZB8nGRhUYjBdv3eg
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.