I’ve been curious for some time about the various methods for controlling content access based on country of origin. If you’ve browsed the European internet or tried to access US video from Canada, you’ve probably experienced a geo fence. It’s different from a paywall and serves a different purpose. I’m using it on this site now, which shows how it can operate without visitors being aware, if they’re not impacted.

The biggest challenge is to gather information from the visitor’s browser in order to determine what country they are from. As I say, whether you spoof your country in browser or use a VPN to bypass geo-fencing, you can appear to be from somewhere you aren’t.

But why? Visitor redirects can help you comply with regulatory requirements related to privacy. They can help you put people in front of content that is written in their primary language without requiring them to look for it.

I looked at three ways to do this:

  • at the firewall. This pushes the challenge and block furthest away from my web site but allows me the least control.
  • at the server. This gives me more control but requires a higher degree of technical knowhow.
  • at the application. This lets visitors get to my web site application (WordPress) before I attempt to redirect their visit.

At the Firewall

My web site is behind Cloudflare’s firewall. It serves a dual purpose of security and content delivery network. The service is free and is a great way to control overall access to your site.

You can create rules based on country of origin and other elements of a visitor’s environment. Since the visitor’s request has to pass through Cloudflare to get either to the cached copy or original page, it’s like an outer fence.

A screenshot of my firewall rules on Cloudflare. You are able to see which requests are blocked – or prompted for a challenge code, like a captcha – and can fine tune the rule. But you can’t redirect visitors to different content.

This is mostly useful if you’re trying to prohibit all access. You can force a challenge – like a captcha code – to reduce bot or automated traffic. But you either let the visitor through or you block them. There’s not a middle ground, so it’s not as nuanced as you might want.

At the Server

When you can reduce requests before they get to your server, you can reduce the bandwidth your server is delivering and the requests it has to respond to. It’s a resource savings. But it’s not always possible.

On non-Microsoft web servers, you can control file and folder access using a file called .htaccess. It can be used to limit access to your site by IP address or other attribute of your visitor’s environment. Your browser sends headers, metadata about your visit. I have used the accept-language to redirect a browser based on the language it indicates the browser uses:

RewriteCond %{HTTP:Accept-Language} (ru) [NC]
RewriteRule .* ofaolain.com/free-paul-whelan.html [L]

This isn’t fool proof. You can take a look at the some of the headers your browser sends. For example, although I’m sitting at a computer in Canada, my browser language is set to en-US, American English. A rule that is attempting to redirect based on country would be inaccurate. Although I could potentially redirect based on language.

It’s that lack of accuracy that makes .htaccess not as useful. You can bypass that using additional web server modules like GeoIP’s Apache module. That will grab the country information separately. Similarly, a visitor coming through Cloudflare will pass the country through in the cf-ipcountry variable.

One challenge I have is knowing what’s going on. It can be hard to test if you’ve got any web site caching going on (is the visitor hitting the cache or rule) and you need a vpn to put yourself in that country. Then there are syntax issues in writing the rules.

I tried the Cloudflare approach. My experience was that it was still not 100% reliable. But I am not very familiar with .htaccess syntax and so the failure is most likely mine. This is similar to the accept-language approach but using the CF-IPCountry variable.

RewriteCond %{HTTP:CF-IPCountry} ^RU$ 
RewriteCond %{REQUEST_URI} !(?:gif|png|jpg|jpeg|css)$ [NC]
RewriteRule ^(/.*)$ https://ofaolain.com/одну-минутку-пожалуйста/ [L,R=301]

I decided to see if there was a way to manage this from within the WordPress application.

At the Application

The difficulty with shifting the testing and redirection to the application is that you still need a way to know if someone is in a particular country. I ended up going with a lightweight WordPress plugin called iQ Block Country. It’s good if your redirect goal is pretty simple.

It relies on the free MaxMind geolocation data sets. If you use the Matomo analytics, you may already have access to MaxMind since Matomo (f/k/a Piwik) uses the same sets. You upload the data to your web site host, in the folder specified by the plugin, and you’re done.

The plugin allows you to set one flow. Anyone who is blocked gets the same message or redirect. That’s fine in my case. But if you wanted to segment the French from the Belgians, or North Americans from the Europeans, you couldn’t. You can also select based on content types, so I can leave my pages, a WordPress content type, open to everyone but restrict and redirect access on my blog posts, another content type.

I’ve implemented it so that visitors from certain countries are forwarded to a page explaining that the content isn’t available in their country. This is the same functionality that you can get from .htaccess. But overall, using a plugin is a less technically challenging approach.

Whatever your purpose, any kind of user-based filtering will leak. IP ranges that form the basis of most country-specific blocking will change. Anonymizing proxies and VPNs can spoof details. You can, in return, block the IP ranges using those tools but it’s a game of whack-a-mole to do so.

My web site does not get a huge amount of traffic – it’s a personal blog – and so I think this will probably be fine. Sites with greater server load would probably want to push this redirect check further out towards the firewall. But I’m impressed by the wide variety of choices that are available to do this from within WordPress.