Is my site blocked in …?

Internet providers block sites inside their own networks, often in their DNS, the address book that turns your domain into a server address. An uptime monitor runs in a datacenter, on a different network with its own DNS, so its test does not pass through those blocks.

Researchers who measure internet blocking from VPN servers in commercial datacenters say such servers may see less blocking than people at home run into.

Source: ICLab (Niaki et al.), IEEE Symposium on Security and Privacy 2020

Sites that were never the target get caught too:

• Spain, 2026. During football broadcasts, providers blocked server addresses linked to alleged pirate streams of the matches. Other sites shared those addresses through a CDN, a delivery network such as Cloudflare that serves many sites from the same addresses. In a single hour, blocking only 4 to 20 of these addresses was enough to disrupt more than 400,000 domains at once. Spain is in testing with us, not available yet.
  OONI, 30 June 2026
• Italy, 2024. On the evening of Saturday 19 October 2024, Italy's anti-piracy system, Piracy Shield, blocked drive.usercontent.google.com, the address Google Drive uses for downloads, for several hours. We do not measure Italy yet.
  Techdirt, 21 October 2024 · Il Post, 21 October 2024

Why datacenter monitors miss ISP blocks · Innocent sites caught by blocks in Europe

Your developer sends us the address of a page and a country. It can be any https page, such as your checkout, not only your home page. You can narrow the check to one provider, or to home or mobile. A check usually finishes within a minute. For each provider and connection type, the answer says whether its customers get your real page. We also check that the page comes with your own security certificate (the digital ID behind the padlock in the browser), not someone else's.

If the page is blocked, the answer says how:

• the provider's DNS sends visitors to a notice page, or says your site does not exist;
• the connection to your server is cut off, or goes silent and never gets an answer;
• something between your visitors and your server shows a security certificate that is not yours, so browsers usually show a security warning;
• the provider, or the CDN in front of your site, shows its own block page instead of yours.

The answer also says when it is not a block: your site is down for everyone, or your own site turned our test away, for example with bot protection or a rule that keeps out visitors from some countries.

Next to the provider answers, every check also reports on the lists and filters that can stop visitors:

• Google's list of dangerous pages;
• Chrome's rules for domains that look like a better-known one, which can trigger its "Did you mean …?" warning;
• public DNS services that filter out harmful sites, such as Quad9 and DNS4EU, which some people use instead of their provider's.

Some providers sell an optional security filter. We test Telenor's Nettvern+ in Norway through customers who have it switched on, and show those results separately, never marked more than "likely". For Vodafone's and O2's optional security filters in Germany we have not found such customers yet, so that part of the answer says "not measured".

Every answer in detail · How a check works

Google Safe Browsing keeps a list of dangerous web pages, and browsers that use it can show a red warning instead of a page on the list. The list can name a single page, such as a new login or checkout page, while your home page and your domain stay clean. Your uptime monitor stays green.

When a browser shows a red phishing warning, most people turn back. In a study of over 25 million browser warnings, Chrome users ignored about 1 in 4 malware and phishing warnings and went on to the site. Firefox users did so about 1 in 10 times.

Source: Akhawe and Felt, "Alice in Warningland", USENIX Security 2013

Every check looks up both the page and its domain in Google Web Risk, the business version of Google Safe Browsing. We do not yet open the page in a real Chrome or Edge browser, so we cannot show the warning exactly as they display it. That part is being built. Microsoft SmartScreen, which Edge uses for its warnings, is not checked yet either.

Red warnings and lost visitors

Our tests run over ordinary customer connections, at home and on mobile, reached through commercial services that sell access to them. Like any connection, they sometimes drop or switch networks halfway through. Right before and right after opening your page, the test connection checks in with our server. If its network changed in between, the result is thrown out and the answer says "our side failed". That never counts as a block, and once billing starts it will not be charged.

A real block repeats. We call a page blocked only when we see the block for at least 3 different customers of that provider, in at least 2 different parts of its network. For the provider answers, we look up your domain from the customer's own line, the way their phone or computer does, not from our servers. Otherwise a block in the provider's DNS would be invisible.

When we are not sure, the answer says so. Without direct proof, such as the provider's notice page, a fake DNS answer or a certificate that is not yours, we mark a block as "likely", not certain. On mobile networks we cannot ask the provider's DNS directly; we only see the answer the customer's phone got. So a DNS block on a mobile network is never marked more than "likely". The answer says "probably opens" (yellow, not green) when the most important check for that country could not be done, such as the provider's DNS for Netia in the example at the top. We have not yet measured our own error rate, so we show no accuracy percentages.

How a check works, step by step

A check can also name other providers on our list, such as 1&1 in Germany, Telia or Altibox in Norway, or the mobile networks of Orange and T-Mobile in Poland. We measure them when we have a suitable test connection on that provider at the time. If we do not, the answer for that provider says "not measured", and it is free.

• Germany. Telekom, Vodafone, Telefónica (O2) and 1&1 are members of CUII, a joint body of rights holders and internet providers. They block the sites it names in their DNS: most send visitors to a notice page, some answer that the site does not exist. Since July 2025, a new site is blocked only after a court order. The list is not officially published. CUII says its notice page had about 50 million visitors in 2024.
  heise online, 16 July 2025
• Poland. CERT Polska, a cyber-security team at the Polish state research institute NASK, keeps a warning list of phishing and fraud sites. Under an agreement from March 2020, Orange, Play, Plus and T-Mobile block the domains on that list. Their DNS sends visitors to a warning page instead, and an entry stays on the list for six months. Orange also runs its own filter, CyberTarcza, which blocked 345,000 phishing domains in 2025.
  CERT Polska · Orange Polska, 31 March 2026
• Norway. On 1 January 2025, Norway introduced DNS blocking of unlicensed gambling sites by internet providers. The gambling regulator, Lotteritilsynet, lists 238 blocked sites run by 72 companies (as of November 2026). In September 2026 it gave notice of plans to block 62 more sites.
  Lotteritilsynet

For any other country, ask for it; demand decides the order.

All countries

Nothing during early access. When billing starts, you will buy credits in advance:

• You are charged per answer. One answer covers one provider and one connection type, for one page.
• You pay only for three kinds of answer: it opens, it is blocked, or it is down for everyone.
• Answers are free when our side failed, the result was unclear, the provider could not be measured or your site turned our test away. If you cancel a check, the answers it has not finished yet are free too.
• Before a check runs, a free preview shows the most it can cost. Once we accept the check, its price is fixed.
• At zero balance, checks stop. There are no surprise invoices.

Prices will be published before billing starts. Pricing in detail

One request starts a check. This is the request behind the example at the top of the page:

curl https://api.linkspect.com/v1/checks \
  -H "Authorization: Bearer $LINKSPECT_KEY" \
  -H "Content-Type: application/json" \
  -H "Prefer: wait=30" \
  -d '{"url": "https://shop.example/checkout/?step=pay",
       "targets": [{"country": "PL"}]}'
# 201 with every answer if the check finishes within 30 s,
# otherwise 202 with the current state; then poll GET /v1/checks/{id}

With the header Prefer: wait=N, the API holds the response for up to N seconds, 30 at most. If the check is still running then, you get its current state and fetch the rest later. Without the header, you get a 202 response at once and fetch the result later. Each answer has the outcome, how the page was blocked if it was, and a short explanation. In our last load test, a check of every main provider in Germany, Poland and Norway finished within 35 seconds half of the time, and within 62 seconds 95 times out of 100.

API quickstart · Verdict reference