The Lead

The U.S. Office of Foreign Assets Control administers over 30 active sanctions programs targeting countries, regimes, and categories of actors, according to OFAC's own Sanctions Programs and Country Information page. If your business is U.S.-based or touches U.S. payment rails, you are already legally prohibited from transacting with parties in several of those jurisdictions — whether or not you have a "block country X" feature turned on in your stack. That is one of three very different reasons operators ask about country blocking, and conflating them leads to the two most common mistakes in this space: blocking Googlebot by accident and blocking legitimate customers who happen to travel.

This guide is for the operator who has been asked to "just block Russia" or "block everything outside our service area" and wants to do it correctly — meaning without nuking your organic search traffic, without violating disability-access or GDPR obligations, and without pretending that an IP's country code is the same thing as a user's citizenship. We'll cover what geoblocking actually means in practice, how accurate the underlying GeoIP data is, where to implement the rules, the SEO trap that catches most teams once, and when you want ASN rules instead.

TL;DR

• Country-level GeoIP is ~99.8% accurate per MaxMind's own data; city-level drops to ~66%. Build policies around country, not city.
• Always allowlist verified crawlers (Googlebot, Bingbot) before your country rule runs. Blocking the U.S. without this exception will de-index you.
• Compliance blocking (OFAC, EU sanctions) is not optional if your business is subject to it — but the legal surface is narrower than most teams realize, and blocking broadly "to be safe" creates its own problems.
• For "I want to stop scraping from country X", ASN-based rules usually beat country-level rules. Most abuse comes from hosting ASNs, not residential networks.

Why Block a Country at All? The Three Legitimate Reasons

Teams conflate three motivations that have almost nothing in common. Keeping them separate is the first step to a policy that works.

Fraud Concentration

Some countries account for disproportionate shares of fraud on specific attack surfaces. Cloudflare Radar's 2025 Year in Review reported that over the first week of March 2025, the United States, Indonesia, and Germany were together the top sources of application-layer DDoS attacks, accounting for over 30% of such attacks. That is useful background context, but it is not a license to block Indonesia — it is a license to *investigate* whether your specific attack patterns disproportionately originate there, and to consider targeted rules on the specific networks involved.

Legal and Sanctions Compliance

This is the hard-edged reason. U.S. persons and businesses must comply with OFAC sanctions — which cover Cuba, Iran, North Korea, Syria, and certain regions of Russia and Ukraine among others — regardless of whether you intended to transact with a sanctioned party. EU-linked businesses have analogous obligations surfaced via the EU Sanctions Map, which aggregates sanctions regimes adopted by the EU or transposed from the UN Security Council. If your product accepts payment, distributes software with export-controlled cryptography, or offers services that could reasonably be construed as material support, "I didn't know they were in Iran" is not a defence.

The bar here is "reasonable diligence" — not "100% effective blocking." That distinction matters because it rules out the false equivalence of "GeoIP isn't perfect, so why bother." You bother because regulators expect a good-faith effort, and because the alternative is consent decrees.

Content Licensing and Pricing

Streaming services block regions where they don't hold rights. SaaS platforms enforce regional pricing (a subscription in India costs less than one in Switzerland). Retailers geoblock because a product launch is jurisdiction-specific or because shipping to that country isn't viable. None of this is "security" blocking — it's commercial policy implemented in the network layer. Accuracy matters here because a false block in this category costs you a paying customer, not an attacker.

The Data You're Relying On: GeoIP Accuracy and Its Limits

GeoIP databases do not know where a user is. They know where the IP address was registered, what the network operator has declared about its netblocks, and what crowdsourced signals (from users who have self-reported their location in apps that query the database) have said over time.

How GeoIP Actually Gets Built

The foundational layer is Regional Internet Registry data. RIRs like RIPE NCC (Europe/Middle East), ARIN (North America), APNIC (Asia-Pacific), LACNIC (Latin America), and AFRINIC (Africa) assign IP blocks to network operators and publish delegation records stating which continent and country each block is registered to. This data gives you continent-level accuracy essentially for free.

ISPs then subdivide their allocations and publish — in some cases voluntarily, in some via vendor-maintained private feeds — finer-grained country and city mappings. A German ISP might declare that a /22 in one of their AS blocks is serving Berlin customers. A U.S. mobile carrier might declare their nationwide IP pool country=US without any useful city information.

Finally, commercial databases (MaxMind's GeoIP2, DB-IP, IP2Location) layer crowdsourced and proprietary signals on top: latency measurements, app telemetry, customer-reported corrections. The result is a database that's updated weekly or more, with varying accuracy depending on how cooperative the underlying networks are.

The Accuracy Numbers

Per MaxMind's own published accuracy data, their GeoIP2 products achieve approximately 99.8% country-level accuracy. That number is high enough to build a sanctions-compliance policy on, with the standard caveat that the remaining 0.2% should have a review process behind it.

City-level is a different story. Within the U.S., MaxMind reports roughly 80% state/region accuracy and 66% accuracy for cities within a 50km radius. Outside the U.S., accuracy varies by country — some European countries are well-covered, many Asian and African countries less so. Mobile carriers are the worst offenders; a cellular IP in the U.S. might be registered to a regional network operations center three time zones from where the user actually is.

The consistent sources of country-level error are satellite internet providers (the IP is registered to the satellite operator, not the user's country), VPN users (the IP is in whatever country the VPN exit node lives in), and IP blocks that have been transferred between organizations without updated registration records. For compliance, the safe move is to block based on the most conservative signal — country *and* declared home network — and log everything so you can show due diligence.

How Country Blocking Actually Works in Production

There are three places to apply the rule. Choose based on your traffic volume and operational constraints.

CDN-Layer Blocking

The cheapest and fastest. Cloudflare, Fastly, and AWS CloudFront all support country-level firewall rules that drop requests before they reach your origin. A Cloudflare WAF rule reading (ip.geoip.country in {"IR" "KP" "SY" "CU"}) short-circuits traffic at the edge, saves origin bandwidth, and applies across every hostname you've put behind the CDN. Latency cost is zero because the rule evaluates on the same edge node already terminating TLS.

Downsides: CDN geolocation is a single source. If your CDN is wrong about an IP's country, you have no second opinion. For sanctions compliance you want a defence in depth — CDN rule plus origin-level verification.

Application-Layer Blocking

Apply the rule in your application code, querying an IP intelligence API on incoming requests. This gives you richer signals (is it a VPN? a hosting ASN? a known residential proxy?) but costs a few milliseconds per request. Here's a minimal Python/Flask example that reads location.country_code from the Predax API:

from flask import Flask, request, abort
import requests, os

BLOCKED_COUNTRIES = {"IR", "KP", "SY", "CU"}
app = Flask(__name__)

@app.before_request
def enforce_country_block():
    ip = request.headers.get("CF-Connecting-IP") or request.remote_addr
    resp = requests.post(
        "https://predax.io/api/v1/check/ip",
        headers={"X-API-Key": os.environ["PREDAX_API_KEY"]},
        json={"ip": ip},
        timeout=2,
    ).json()
    if resp.get("location", {}).get("country_code") in BLOCKED_COUNTRIES:
        abort(451)  # Unavailable For Legal Reasons

HTTP 451 is the right status code for compliance-driven blocks — it signals to well-behaved clients that the block is legal, not technical. For fraud-driven blocks, 403 is more conventional.

Database-Side Blocking

If you run your own GeoIP table (MaxMind's free GeoLite2 CSV import, for example), you can join on a country_code column in your normal query path. This is the cheapest per-request option at steady state but the most operationally painful — you own the data freshness problem, and stale GeoIP data will misroute users as netblocks get reassigned.

For most operators, CDN-layer blocking with application-layer verification on sensitive endpoints (checkout, signup, payment) is the right architecture. Use the Predax API documentation if you want to wire a second-opinion check behind your CDN rule.

The SEO Trap: Don't Accidentally Block Googlebot

Here is the mistake almost every team makes once. You add a country block, deploy it, and a few weeks later your organic traffic craters. What happened: Googlebot crawls primarily from U.S.-based IP ranges, and if your rule blocks U.S. traffic — or if it blocks by risk score and Google's IPs get flagged as "datacenter" — you've just told Google that your site doesn't exist.

Where Googlebot Crawls From

Google publishes their crawler IP ranges at developers.google.com/static/search/apis/ipranges/googlebot.json, updated daily. The largest blocks are in 66.249.64.0/19, with smaller ranges scattered across Google's U.S. datacenters. There are no Googlebot IPs in Russia, China, or most of the countries you'd plausibly want to block.

How to Verify Googlebot Properly

IP allowlists are a brittle solution — Google rotates crawlers, and a stale allowlist will eventually block them. The durable method is forward-confirmed reverse DNS (FCrDNS), documented officially by Google Search Central. The two-step process:

1. Reverse-DNS the incoming IP. Confirm the hostname ends in googlebot.com, google.com, or googleusercontent.com.
2. Forward-DNS the hostname. Confirm it resolves back to the same IP.

Any bot claiming to be Googlebot but failing step 2 is spoofing the user agent. Real Googlebot always passes both checks. The same technique works for Bingbot (search.msn.com), Yandex (yandex.ru/yandex.net/yandex.com), and Baidu (baidu.com).

What Happens If You Get This Wrong

Google's documentation explicitly warns that if your server serves error pages or blocks Googlebot, the crawler will first treat those as soft-404s and — if persistent — drop the affected URLs from the index. You don't get a warning email. Your rankings just decay over a few weeks. Recovery is slow: Googlebot has to re-crawl the pages, confirm they're accessible, and requeue them for indexing, which can take months.

Non-Google crawlers carry similar risks in their home markets. Yandex crawls primarily from Russian IPs — so blocking Russia without exempting verified Yandex bots will kill your Yandex organic traffic. Baidu crawls from China. If your market includes these search engines, apply the same FCrDNS allowlisting to their crawlers.

When ASN-Level Blocks Beat Country-Level Blocks

Country rules are a blunt instrument. Most people asking "how do I block Russia" actually mean one of two more specific things:

1. "I want to stop scrapers from Russian hosting providers."
2. "I want to comply with a regulation that targets specific sanctioned entities."

For case 1, ASN rules are strictly better. Scraping and abuse traffic mostly does not come from residential eyeball ISPs — it comes from hosting ASNs like Selectel, Timeweb, Reg.ru, DigitalOcean, and Hetzner. Blocking "Russia" at the country level hits everyone in Russia including residential users on mobile networks, most of whom are not scraping you. Blocking the hosting ASNs specifically catches 80%+ of the abuse with a fraction of the collateral damage.

This ties directly to the residential-vs-datacenter distinction we cover in detail for proxy-style traffic. The same logic applies to country-level decisions: blocking by ASN and hosting classification reflects actual intent far better than blocking by country flag.

When Country Rules Are Still Right

Two cases. First, sanctions compliance — the regulation is written at the country level, so your rule has to be too. Second, when you genuinely don't serve a market for commercial reasons (streaming rights, shipping policy, regional pricing that would arbitrage if you let out-of-region users subscribe). For these, the country rule is the correct abstraction.

Pair Country and ASN Rules

The best real-world policies layer both. Country rule for compliance and commercial policy; ASN rule for abuse prevention; and a separate rule for anonymizing networks, where you'd typically pair country blocking with Tor exit blocking to catch sanctioned-region traffic that comes in through anonymizers.

Compliance Nuance: Why GDPR Makes This Tricky

Country blocking for EU visitors runs into GDPR's international data transfer rules. Article 44 of the GDPR establishes the general principle that any transfer of personal data to a third country (outside the EU/EEA) is permitted only if the protections Chapter 5 requires are in place — adequacy decisions, Standard Contractual Clauses, Binding Corporate Rules, or a limited set of derogations.

This cuts both ways. On one hand, geoblocking EU visitors to avoid GDPR scope is a known (if frowned-upon) tactic used by some U.S. publishers after 2018. On the other hand, if you *process* an EU visitor's IP address in order to decide whether to block them — which you do, every time you geoblock — you've already engaged in personal data processing that needs a lawful basis under Article 6.

The practical implication: your privacy policy needs to disclose that you process visitor IP addresses to determine geographic origin, and you need a legitimate interest (security, legal compliance) or another lawful basis for doing so. Most operators cover this under "site security and fraud prevention" in their privacy policy, which is generally accepted.

Accessibility law adds another wrinkle. In jurisdictions with strict accessibility regulations (U.S. ADA case law, EU Accessibility Act), blocking access to a public-facing service has been argued in courts as creating an accessibility barrier. The case law is thin and evolving. If your site is subject to accessibility regulation, don't deploy a country block without legal review.

Standard disclaimer: this post is not legal advice. Compliance policies should be reviewed by qualified counsel in your jurisdiction before deployment. We're describing the technical shape of the problem, not telling you what your obligations are.

How Predax Helps

Country blocking in production is not just "does my GeoIP vendor return the right country code." It's a handful of questions that all have to be answered together: Is this a verified crawler I should exempt? Is the IP actually in the country it claims, or is it on a hosting ASN that just happens to have been allocated in-country? Is it a VPN exit in a blocked country masking a user in an allowed one? The signals for each of these live in the same IP-intelligence call.

Every call to /api/v1/check/ip returns `country_code` for the geolocation decision, `asn` and `asn_org` for the network-operator identity, and `is_hosting`/`is_residential`/`is_cloud` classification flags that let you distinguish "real Russian residential user" from "hosting VM that happens to be colocated in Russia." Combine them and you can write a policy like "block OFAC-listed country codes at the CDN, then at the application layer exempt verified search-engine crawlers, challenge residential VPN users with a legitimate appeal path, and hard-block hosting ASNs regardless of country." The response is a single JSON object; you read the fields you care about.

For WordPress and WooCommerce operators, the lower-level API is wrapped in plugin UI. The WooCommerce plugin's Country Restrictions feature accepts a blocklist or allowlist of country codes and applies it at checkout — useful for shipping-policy enforcement or compliance-driven order blocking. The WordPress plugin's IP-based access rules let you configure allowlists and blocklists with CIDR support, test rules against a synthetic IP, and audit every blocked request in the plugin's event log.

None of this replaces a lawyer's review of your sanctions obligations or a hardened edge WAF for DDoS. It gives you the network-layer signals correctly, so the policy you build on top reflects reality rather than guesswork. View pricing for the plan tiers, including a generous free plan for small-scale production use.

Frequently Asked Questions

Is country blocking legal?

In most jurisdictions, yes — private operators generally retain discretion over who they serve, subject to anti-discrimination law and sector-specific regulation. In some cases blocking is legally required: U.S. persons and businesses must comply with OFAC sanctions programs regardless of intent, and EU-linked businesses face analogous obligations under consolidated EU sanctions. Public-sector sites and regulated industries (healthcare, financial services, accessibility-mandated services) may have narrower latitude. This is not legal advice — when you're blocking for compliance rather than operational reasons, get a lawyer to review your policy before you ship it.

Will blocking a country hurt my SEO?

Only if you block the wrong IPs. Googlebot primarily crawls from U.S.-based IP ranges published by Google, so a country-level block on Russia, China, or Iran will generally not touch Googlebot. Blocking the United States without an exception for Google's published ranges is the fast way to tank your organic rankings — Google's docs explicitly warn that serving blocked content to crawlers can cause soft-404s and eventual de-indexing. The safe rule: always allowlist verified crawler IPs (via the forward-confirmed reverse DNS method documented by Google Search Central) before any country rule runs.

How accurate is GeoIP at the city level?

Much less accurate than at the country level. MaxMind publishes that their GeoIP2 databases achieve roughly 99.8% country-level accuracy for U.S. IPs but only around 66% accuracy at the city level within a 50km radius, per their own geolocation accuracy page. State/region accuracy sits near 80%. Mobile carriers, VPNs, and IP blocks transferred between organizations without registration updates are the primary sources of error. If your policy depends on city-level precision — say, blocking a specific metropolitan area — the error rate is high enough that you should treat the signal as advisory, not determinative.

What's the difference between IP geolocation and ASN?

IP geolocation answers "roughly where is this IP physically?" ASN — Autonomous System Number — answers "what network operator announces this IP to the internet?" Geolocation comes from a mix of Regional Internet Registry data, ISP netblock declarations, and crowdsourced observations. ASN comes directly from BGP routing tables and is managed by RIRs like RIPE NCC. ASN tells you the IP belongs to DigitalOcean, Amazon, or Comcast; geolocation tells you the suspected country or city. They're complementary — a DigitalOcean IP might be geolocated to Germany, but the useful signal for most bot defence is that it's a hosting ASN, not that it's in Frankfurt.

Related guides

• ASN-based blocking explained — when ASN is a sharper filter than country.
• How IP risk scoring works — combining geography with risk signals instead of using either alone.
• How to detect VPN users — the obvious bypass for any country block, and how to handle it.