How to Block Countries in WordPress Without Blocking Real Customers

To block countries in WordPress safely you need three things: a reliable way to know where a visitor is, a rule that says who is blocked, and a test run that shows you who that rule would hit before it hits anyone. Most geo-blocking mistakes come from skipping the third step. Here is the whole process, including the exemptions that keep search engines and payment providers working.

Decide: block list or allow list

There are two ways to use geo rules and they fit different sites.

Block list. Everyone is allowed except named countries. Use this when your logs show a few countries sending nothing but login attempts, comment spam and vulnerability scans, and you have no customers there. It is low risk because the default is open.

Allow list. Only named countries are allowed. Use this when you genuinely serve one region, for example a local service business or a shop that ships to two countries. It is higher risk, because a single missed country blocks real people, so it needs the test step even more.

If you sell globally, do neither for the public site. Instead, protect the login and admin area only. That gives you most of the benefit with none of the lost customers.

Pick your country source

A plugin needs to turn an IP address into a country. Two free options cover almost every site:

Cloudflare headers. If your site is behind Cloudflare, every request arrives with a country code that Cloudflare derived from the connecting IP. It is accurate and costs nothing extra. The plugin should verify the request really came through Cloudflare before trusting the header, or anyone can forge it.

Local GeoIP database. For sites not on Cloudflare, a database on your own server maps IP ranges to countries. It covers IPv4 and IPv6 and needs refreshing roughly monthly as ranges move. DevDome Country Blocker supports both: verified Cloudflare headers when available, otherwise a free local database refreshed automatically each month. We make it, so weigh that, but the two-source approach is what to look for in any plugin.

Set up the exemptions first

Before writing a single block rule, list who must always get through:

• Search engine crawlers. Googlebot and Bingbot crawl mostly from the United States, but not only. Exempt verified crawlers by identity, not by country.
• Uptime monitors and backup services. They probe from data centres around the world.
• Payment and webhook providers. Stripe, PayPal and your email service send server-to-server calls. If you block their region, orders silently fail.
• Your own IP and your team. Especially if the admin area will be restricted.

A plugin that offers an exemption list by IP, by user agent verification, or by path makes this manageable. If yours does not, do not restrict the admin area until it does.

Run it in test mode

This is the step that saves you. Turn the rules on in a mode that logs who would be blocked without blocking anyone. Let it run for a few days, longer if your traffic is small. Then read the log:

• Are there real customers, newsletter readers or partners in the “would block” list? Adjust the rule.
• Are search crawlers showing up? Fix the exemption before going live.
• Is the list mostly login attempts, scanner hits and spam? Good, that is what you are aiming at.

Only after the log looks right do you switch from test mode to blocking. If you ever change the rule later, go back to test mode first.

Choose what blocked visitors see

A plain 403 page is honest and cheap. Avoid redirecting blocked visitors to another site or a different URL; search engines can follow redirects and it causes confusing reports. If you allow-list for a regional business, a short message with a contact email is friendlier than a blank error, since legitimate travellers will hit it.

Never show a CAPTCHA or challenge page to everyone to work around geo rules. It costs real visitors and bots solve them anyway.

Know what geo blocking does not do

Geo blocking is noise reduction, not a wall. Anyone with a VPN or a proxy in an allowed country gets through, and sophisticated bots already rent such addresses. What you remove is the bulk of lazy, untargeted traffic: automated login attempts, comment spam and vulnerability scanners that come from a handful of networks.

So keep the rest of the basics: updates, strong passwords, two-factor for admins, a malware scanner, and bot protection that recognises scanners by behaviour rather than location. Country rules make those tools’ logs quieter and their jobs easier.

Reading the test-mode log

The log from a week of test mode is a list of requests that would have been blocked, with country, path and user agent. Read it in three passes. First, search for anything that looks like a search engine or a service you use; those need exemptions before you go live. Second, look at the paths: a log dominated by wp-login.php, xmlrpc.php and plugin probes is exactly the traffic you want gone. Third, look for ordinary page requests from the blocked countries with a referrer and a normal browser; those are people, and if there are more than a handful you have a real audience there and should narrow the rule to the admin area instead.

A sensible default for most sites

If you are unsure where to start, this setup works for the majority of small and mid-sized sites:

1. Leave the public site open to every country.
2. Restrict wp-login.php and the admin area to the countries where your team actually lives.
3. Exempt verified crawlers, your monitors and your own IP.
4. Run in test mode for a week, read the log, then block.
5. Review the log monthly and adjust.

That removes most automated attacks from your login page, costs no customers and takes under an hour.

Related reading: How to Remove WordPress Admin Notices Without Breaking Anything.

Related reading: WordPress Activity Log: Who Changed What, and Why You Need One.