At Kinsta it is possible to use GeoIP to tailor the performance of your website.
In order to enable this functionality Kinsta’s support team must enable the nginx GeoIP module. Once the module has been enabled Kinsta’s support team can work with you to determine the appropriate implementation of GeoIP for your website.
Limitations to Free Support of GeoIP
Please note that Kinsta’s responsibility with regard to GeoIP is simply enabling the module in nginx and adding the necessary nginx rules. Developing the underlying web pages and website functionality remains the responsibility of the user. In other words, Kinsta can help you redirect visitors from a specific country to a specific page, but it’s still your responsibility to create that webpage.
Still looking for that perfect WordPress host?
- Fully managed
- Secure like Fort Knox
- Free migrations
- Ultimate speed
- Daily backups
- Google Cloud Platform
Our free support for the use of GeoIP is limited to no more than five custom GeoIP-based rules. If you require extensive customization we may propose a one-time add-on fee to assist you with setup.
A Kinsta we support country-level GeoIP functionality. We do not support more detailed targeting such as city or organizational level targeting.
GeoIP rules can only be modified by Kinsta’s support team. They are uploaded directly to the site’s nginx configuration and therefore cannot be accessed or modified directly by our customers.
Common Uses of GeoIP
The three most common GeoIP implementations include:
- Redirection based on the visitor’s detected location.
- Page cache differentiation based on the visitor’s detected location.
- Blocking traffic from specific geographic locations.
Let’s briefly consider these uses.
- Location-Based Redirection
- Location-Based Cache Differentiation
- Location-Based Traffic Denial
- Combining GeoIP Functionality
Let’s say you have a website at example.com. Imagine that you build a new page specifically targeting visitors from the UK and you wish to have all visitors from the UK redirected to example.com/uk/. This can be accomplished relatively easily with the nginx GeoIP module.
Kinsta’s support team would need to enable GeoIP and then add a redirection that would detect the visitor’s location and redirect visitors from the UK to example.com/uk/.
It would be possible to expand this arrangement as needed as well. For example, our support team could relatively easily set up the following arrangement:
- Rule 1: Visitors from the UK redirected to example.com/uk/
- Rule 2: Visitors from the United States and Canada redirected to example.com/us/
- Rule 3: Visitors from Mexico redirected to example.com/mx/
- Rule 4: Visitors from India redirected to examplecom/in/
- Rule 5: Visitors from Australia redirected to example.com/aus/
- No rule triggered: All other visitors to remain at example.com
Note that the above configuration would be considered a total of five GeoIP rules. As noted earlier in this article, 5 rules are the limit for our free support of GeoIP. If more complex GeoIP functionality is needed a one-time setup fee may apply.
Location-Based Cache Differentiation
Some plugins and themes include features that detect the visitor’s location and customize content such as language or currency based on the visitor’s location. By default, with page caching such as what is enabled at Kinsta, this information would be generated for the very first visitor and then subsequent visitors would all see the information that was generated for the first visitor. The reason this happens is that the first visitor’s pageview was cached and delivered to all subsequent visitors.
The solution to this issue is to use GeoIP to build separate caches for each country for which content is customized.
Let’s consider an example to see how this could be applied in practice. Imagine that you have a website, example.com, that displays pricing in Euros, British Pounds, and US Dollars. You set up a plugin to automatically switch between these three currencies based on the visitor’s detected location. Kinsta’s support could use GeoIP to build three separate cache buckets to make it possible to display the right currency based on location while simultaneously continuing to use our server caching to keep the site fast and scalable.
- Rule 1: Cache visitors from the USA in cache bucket 1. Website configured by the user to display US dollars.
- Rule 2: Cache visitors from the UK in cache bucket 2. Website configured by the user to display British pounds.
- No rule triggered: Cache bucket 3 if for all other visitors. Website configured by the user to display Euros for all other visitors.
Location-Based Traffic Denial (Geo-Blocking)
Blocking traffic based on geography (also known as geo-blocking) is the simplest use-case to understand.
Imagine that you are running a business that can only sell to visitors from a specific country. Kinsta’s support could easily block access to the site to just visitors from a single country and either deliver a simple “403 Forbidden” message to all other visitors or redirect them to the landing page of your choosing.
Note that Kinsta’s support team is geographically distributed and our uptime monitoring system is also geographically distributed. So while we’re happy to set this sort of limitation up for you there would be implications for both support and uptime monitoring. Our support team will need the ISO codes for the countries you want to block.
Combining GeoIP Functionality
It is also possible to combine multiple types of GeoIP-based rules. For example, the following configuration could be accommodated:
- Rule 1: Visitors from the USA redirected to example.com/us/.
- Rules 2, 3, and 4: Separate cache buckets created for visitors from the USA, Canada, and Europe.
- Rule 5: Visitors from another country where the advertised service is not available blocked entirely.
Setting up GeoIP
To get started on the process of enabling GeoIP on your website simply reach out to our support team using the chat feature in MyKinsta and provide a detailed explanation of your location-based redirection, caching, or access denial requirements.