Geolocation FAQ

If you have set up a geotargeted content and it doesn’t seem to be working as expected, follow the troubleshooting steps below. Each step covers a common issue and how to verify it.

1. Are you testing the site on a local server or internal environment?

The geolocation condition uses an external API to identify the visitor’s location. It can only work on a live, publicly accessible website. Local or internal environments do not support IP-to-location lookups.

2. Is there a communication issue between your server and ours?

• In your WordPress dashboard, go to If-So → Geolocation.
• Look at the value next to “Sessions used this month.”

If it shows 0/0, it usually means your server cannot reach our geolocation service.
Please fill out this form and our support team will take it from there.

3. Are you testing the site using a VPN?

If-So’s geolocation condition may not take action when browsing the site through some VPNs. If you don’t see the geo-targeted version, it doesn’t necessarily mean the condition isn’t working properly.

Instead, try:

• Targeting your own actual country to verify the trigger – Set the condition to “Is” > {your country} to confirm the content displays correctly, or set it to “is not” > {your country} to verify that the fallback or default version appears.
• Here is the corrected and polished version:
• Try testing the page using an online proxy server or a different VPN. We use NordVPN for our testing.

4. Are you using a caching plugin or CDN?

Caching shows visitors a pre-rendered version of the page. If you use a caching plugin, server cache, CDN, or any type of page caching, enable If-So’s Page Caching Compatibility option to ensure your geotargeted content loads via Ajax after the cached page is served.

• Go to If-So → Settings.
• Enable the Page Caching Compatibility options

Elementor users:

In adittion to the steps above, go to Elementor → Settings → Performance (tab) → Change the Element Cache to Disable, and let me know if it solves the problem.

For a deeper explanation of page caching and If-So’s caching compatibility.

5. Is your location being detected inaccurately?

No IP-to-location service is 100%. The accuracy of a location depends on many factors, the most important being the ISP of the address. The accuracy is generally higher for fixed lines than it is for cellular networks. Learn more here about geolocation accuracy.

Below is how If-So recognizes your location. If you have set up a trigger targeting your actual location but the detected value is incorrect, the dynamic version will not be displayed as expected.

Do you see the correct location in the above list?

✅ Yes → Double-check that your dynamic content is being loaded via Ajax (see the step above).

❌ No → Check out the three options below:

1. Accuracy issues can be corrected within 24 hours – Fill out this form and we will ask our database provider to review and correct the IP record.
2. If you are targeting users at the city level, consider using our HTML5 Geolocation API instead of, or in addition to, the IP-to-location service.
3. Consider adding a Location Override Form to let users select their correct location manually.

6. Do you have enough geolocation session credits?

Unlike other If-So conditions, geolocation usage is limited by monthly sessions. If you run out of credits, the default content (fallback content) will be displayed instead of the geotargeted version.

To view your monthly session usage, go to If-So → Geolocation in your WordPress dashboard.

7. Are you using Cloudflare?

From time to time we encounter conflicts between our geolocation service and Cloudflare. We can solve them! Paste the following code at the end of your functions.php file and try again. If it doesn’t solve the problem, please contact our support.

add_filter('ifso_user_ip',function(){
$ip = null;
if (!empty($_SERVER['HTTP_CF_CONNECTING_IP']))      //Cloudflare
$ip = $_SERVER['HTTP_CF_CONNECTING_IP'];
elseif (!empty($_SERVER['HTTP_CLIENT_IP']))
$ip = $_SERVER['HTTP_CLIENT_IP'];
elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR']))
$ip = explode(',',$_SERVER['HTTP_X_FORWARDED_FOR'])[0];
else
$ip = $_SERVER['REMOTE_ADDR'];

if(!empty($ip)){
$ip = explode(':',$ip)[0];
}

return $ip;
});

Country: [ifsoDKI type='geo' show='country' ajax=’yes’ fallback='']
State: [ifsoDKI type='geo' show='state' ajax=’yes’ fallback='']
City: [ifsoDKI type='geo' show='city' ajax=’yes’ fallback='']
Continent: [ifsoDKI type='geo' show='continent' ajax=’yes’ fallback='']

Related FAQs

• The geolocation session count doesn't seem accurate

  The geolocation service is powered by an IP-to-location API. When a user visits a page with a geolocation condition or DKI shortcode for the first time during their session, a request is sent to the geolocation database to compare the user’s IP with the location information stored in the database.

  What is a geolocation session?

  A geolocation session starts when a visitor first accesses a page with a geolocation trigger or a Geolocation DKI shortcode and lasts until the visitor closes their browser or has been inactive for 25 minutes (note that this time frame may vary slightly depending on the browser and server hosting the website).

  Not every page view should count as a session!

  1. The geolocation session is initiated only when a visitor accesses a page with a geolocation trigger or a geolocation DKI shortcode, and a request to the IP-to-location API is made to compare the visitor’s IP with the location in the database.
     
     
  2. If the user browses several pages within the same visit, it will still be considered a single session. The session will end when the visitor closes the browser or after 25 minutes of inactivity, though this duration may vary slightly depending on the browser and server.

  Blocking IPs from the geolocation service

  If-So offers two options to help identify and block bots — we recommend using both.

  1. “Block Bots” mode – automatically blocks search engines and bots that declare themselves as bots.
  2. Manual blocking – logs all geolocation requests, provides a list of IPs that extensively tri

  Click here to learn how to activate these options.

If the value of the “Sessions used this month” is 0/0 then it’s probably a communication failure between your server and ours. Don’t worry, we can easily solve it. Please try to activate geolocation or a free-trial license and use the form below to send us your domain:

If your redirect doesn’t fire immediately, the issue is usually related to how the trigger is loaded. Here’s how to ensure the redirect runs as quickly and smoothly as possible:

Why Ajax affects redirect speed

When a trigger loads with Ajax, the dynamic content is fetched after the static part of the page has already loaded from the cache. This means the redirect can only occur once the Ajax request finishes — resulting in a short delay.

Strong caching paired with inefficient site construction can cause redirects to feel slower.

How to speed it up

To make the redirect fire instantly:

1. Make sure to load the trigger without Ajax. The best practice is to add the parameter ajax=”no” to the trigger’s shortcode so that even if you change the Ajax settings on your site in the future, the trigger with the redirection will not be affected.

   Disabling Ajax means the page must be excluded from caching, so weigh this decision based on SEO needs, performance, your specific use case, and how well the page performs without caching

2. Use a 301 or 302 redirect (and not a JS redirect).
3. Consider embedding the If-So trigger to the page using a PHP code directly in the page template.

It appears that there is a communication issue between our server and yours. No need to worry though, we can resolve it. Kindly follow these two steps:

1. Please attempt to activate a license on your site. Although the activation may not be successful, the information necessary for troubleshooting will be automatically sent to our team (you can get a free license here).
2. Fill out the form below, providing us with your website’s URL.

Stay calm and refer to our Geolocation Troubleshooting guide for assistance.

Inaccurate session counts can occur when bots visit the website. Learn about possible solutions to address this issue.

If you are unable to see the country flags, it is likely because your browser does not support emoji display by default (Google Chrome on a desktop for example).

Browsers that have built-in support for displaying emojis

If your conditional redirect isn’t working as expected, don’t worry – follow the steps below to identify the issue and get it resolved quickly.

1. Isolate the problem

Test the redirect outside the trigger

Paste the redirect shortcode directly into the main content field of a new test page (without using a trigger).

1. Create a new blank test page.
2. Paste the redirect shortcode directly in the main content area (without using a trigger or dynamic content).
3. Visit the page and see whether the redirect works.

Did it work?

✅ Yes → The redirect code works. Move on to checking your condition.
❌ No → The issue is likely with the redirect setup. Jump to the “Redirect shortcode issues” section.

Verify that the condition is being met

1. In your trigger (or dynamic content block), add a simple text indicator before the redirect — e.g., “This is a version A”.
2. Add a text indicator to the default version — e.g., “This is the default version.”
3. Visit the page in an incognito window (to avoid admin/existing-cookie interference).

Does it work?

✅ Yes → If you the correct version the issue is either the redirect type or a caching issue.
❌ No → If you don’t see the correct version → The condition may be misconfigured, or caching is preventing the dynamic version from loading.

Works? The issue is likely related to the redirect shortcode itself, or a caching conflict.
❌ Didn’t work? The condition may be misconfigured or the content might be blocked by caching.

2. Check caching settings

Caching is the most common reason redirects don’t fire as expected.

1. Try loading the trigger with and without Ajax (Page Caching Compatibility) to determine if caching is interfering. How to enable/make sure the Ajax loading is enabled.
2. Try switching to a JavaScript redirect by adding the parameter type=’js’ to your redirection shortcode. For example:

[ifso-redirect url='https://example.com' type='js']

If JavaScript redirection works, the issue is almost certainly caching-related.

Try loading the content with and without Ajax (Page Caching Compatibility) to determine if caching is interfering. How to enable/make sure the Ajax loading is enabled. 

Still not working? We’ll help!

If the issue persists, please contact our support and share the following:

• Where the redirect is placed (page, trigger, element, popup, etc.).
• Which condition you’re using.
• Whether the redirect works on a blank test page.

We’re happy to take a look and help troubleshoot further. Contact support

If you encounter a warning that starts with:

Warning: session_start(): open(/var/cpanel/php/sessions/....)

Or with:

Warning: session_start(): Failed to read session data: (path: /var/cpanel/php/sessions/...)

It’s probably because of a lack of PHP writing permissions to the directory where sessions are set to be saved (you can see the path on the error message).

To fix this, you could either select “Disable use of PHP sessions” in if-so settings (on your WordPress dashboard), or contact your hosting company and ask them to change the session saving path (or allow PHP write access to it).

Coming soon…

If you encounter this problem, please feel free to contact us at support@if-so.com.

The geolocation service is powered by an IP-to-location API. When a user visits a page with a geolocation condition or DKI shortcode for the first time during their session, a request is sent to the geolocation database to compare the user’s IP with the location information stored in the database.

What is a geolocation session?

A geolocation session starts when a visitor first accesses a page with a geolocation trigger or a Geolocation DKI shortcode and lasts until the visitor closes their browser or has been inactive for 25 minutes (note that this time frame may vary slightly depending on the browser and server hosting the website).

Not every page view should count as a session!

1. The geolocation session is initiated only when a visitor accesses a page with a geolocation trigger or a geolocation DKI shortcode, and a request to the IP-to-location API is made to compare the visitor’s IP with the location in the database.
2. If the user browses several pages within the same visit, it will still be considered a single session. The session will end when the visitor closes the browser or after 25 minutes of inactivity, though this duration may vary slightly depending on the browser and server.

Blocking IPs from the geolocation service

If-So offers two options to help identify and block bots — we recommend using both.

1. “Block Bots” mode – automatically blocks search engines and bots that declare themselves as bots.
2. Manual blocking – logs all geolocation requests, provides a list of IPs that extensively tri

Click here to learn how to activate these options.

No IP-to-Location service is 100% accurate. The accuracy of a location depends on many factors, most importantly the ISP of the address. Accuracy is generally higher for fixed lines than it is for cellular networks.

If our service fails to detect your location, please send us an email including your IP and your actual location at support@if-so.com. It usually takes about 72-96 hours for the database to be updated.

You can learn more here about geolocation accuracy.

You might be interested

The locations on this page are displayed using our Geolocation DKI shortcodes. You can do the same on your website using If-So.