How to tell your ISP about a persistent robot block

A robot check can make a working internet connection feel broken. The page says it needs to verify you are human, then the same message appears on another visit or in a different browser. Knowing how to tell your internet service provider about a persistent robot block starts with separating a website’s security check from a fault in your own connection.

In Australia, the provider’s name matters because the retail market includes Telstra and Bigpond, Optus, Vodafone, TPG, iiNet and Australian Broadband, along with smaller NBN resellers. The company supplying your internet may not operate the access network, so record both the ISP shown on your bill and the NBN or fixed-line details in your account.

Before contacting support, gather a few facts and test where the problem follows you. Australian support teams often work during standard business hours, with eastern states on AEST or AEDT and Perth on AWST, so timestamps and a clear record make a follow-up easier.

Separate a network block from a website challenge

Most robot checks are generated by the website rather than the ISP. The site may be testing JavaScript, cookies, your browser profile, IP reputation or a combination of these. A false positive can occur when a household address is shared, a VPN is active, or security software sends traffic through a server that resembles an automated bot.

By contrast, an ISP-side problem may affect DNS, routing or IPv6 connectivity. Test the affected URL on another device using the same Wi-Fi, then try it on mobile data. If it works on mobile but not home Wi-Fi, give your provider the comparison; if it fails everywhere, explain the second result as well.

Check the obvious causes without turning the process into a guessing game. Confirm that the device clock and automatic date are correct, pause a privacy-focused browser extension if it changes the result, and try a normal private window. Clear only site data for the affected domain rather than resetting the whole router. These steps can reveal a local browser conflict, but reconnecting often assigns a new public IP and temporarily changes the symptom.

A provider usually cannot switch off a site’s CAPTCHA, but it can check whether your public IP is being rate-limited, whether a DNS resolver is intercepting the page and whether traffic is taking an unusual network route. That distinction should shape your requested outcome: diagnosis and a supported workaround are realistic; removing another organisation’s security control is not.

Capture evidence before resetting anything

Record the evidence before changing DNS settings, reinstalling software or clearing every cookie. Note the full URL, date and time in AEST or AEDT, the exact error, your browser and operating system, and whether a second device behaves differently. Screenshots should include the address bar and the complete message so support can distinguish a security challenge from a DNS error.

Shared Australian library or council computers can also retain old browser data or run under restrictive network controls. On a public machine, follow public computer safety steps before deleting anything that belongs to another user or changing security settings. A fresh profile on your own phone can provide a cleaner comparison than repeatedly retrying the blocked page.

Contact the provider through the right channel

Use the provider’s official app, account portal or the support number printed on the bill. Large providers such as Optus or Telstra may route robot-check reports through general technical support, while smaller Australian ISPs may rely heavily on email tickets and account managers. A concise ticket creates a written reference even if you first speak to someone on the phone.

Describe the symptom in plain English: “This security check repeatedly identifies my connection as automated from [date], using [browser] on my home network.” Add the affected URL, the comparison already completed and the practical result you need, such as reaching an account page. Avoid vague words such as “broken internet”; they can send the issue to the wrong team.

If the affected URL leads to a gambling platform, name the operator and identify whether age, location or anti-bot verification is failing; this gambling page example shows why the stage of verification matters. Keep screenshots within the relevant service and do not include passwords, one-time codes or identity documents unless the provider’s secure upload process specifically requires them.

Write a support message that gets a useful response

Your message should separate facts from assumptions. State that the connection works on mobile data, if true, and that other sites load normally, if true. Do not claim that the ISP has blacklisted your IP unless a representative has confirmed it. Include your account number in the secure message field, but keep it out of the subject line or public forum.

Ask for a specific diagnostic outcome: whether the provider sees a network or IP-reputation problem, whether DNS or IPv6 is involved, and whether another technician can review the case. If the ISP resells NBN access, ask which part of the service it controls and where the remaining issue belongs. A request for an expected update time is reasonable, especially during busy periods or near the end of the Australian eastern daylight-time change.

Keep the requested help proportionate. Ask the ISP to confirm account and line status first, since a disconnected NBN service or provisioning fault has a different path from a single site’s challenge. If the same block appears on several unrelated domains, provide evidence for each; if it appears only on one, say so. That pattern helps the technician decide whether to inspect routing, filtering or an address-level reputation issue.

Prepare a concise escalation pack

A short evidence pack prevents each reply from restarting the troubleshooting. Keep the material in one note or ticket and include only information needed to reproduce the problem.

Evidence to include

Then use the same facts to request an escalation rather than simply asking for the block to be removed.

Escalation steps to request

If the provider does not respond or refuses to address an eligible fault, consider the Telecommunications Industry Ombudsman. The ACCC can direct consumers to the appropriate dispute process, and state or territory consumer-affairs bodies may handle a service dispute that falls outside the TIO’s scope. This route is not a substitute for technical evidence; keep the original ticket and every response.

Keep a safe connection while support investigates

While the case is open, use a trusted mobile hotspot or another network to complete essential tasks involving my.gov.au, banking or health services. Do not disable TLS warnings, install unknown browser extensions or repeatedly solve challenges on a suspicious page merely to force access. If only one domain is affected, switching networks may restore it temporarily without proving the provider has fixed the underlying issue.

Keep copies of screenshots, ticket references, support promises and dates, and note whether each test changes the result. The practical takeaway is to send one concise packet—exact URL, local timestamps, device comparisons and a clearly requested diagnostic—then follow the provider’s escalation path with that same record until you receive a specific resolution.