I have implemented user IP detection to several of my eCommerce sites, so that it shows the currency and delivery charges based upon the users location. All is good, and this system has been working for a while, but I have began to notice a worrying side effect with the search engines.

Google seems to only crawl websites using US based IP's; country searches such as on google.co.uk now show prices by default in $'s (within the listings), which are reducing the number of click-throughs as prices are no longer being shown in the user's local currency.

The impact is even greater as these are all UK based sites. Even though they are setup to sell to the global market, we still want to keep our local market strong.

One way could be to exclude the currency/delivery detection for the spider IP range, but the same still applies; we have a big following in Europe, US, Australia and New Zealand who convert better if they see their local currency within the search listings.

There are product feeds setup with google, but these don't filter into the main search listings.

The alternative route is to implement country targeting through subfolders/subdomains (/uk/, /us/, /fr/, /it/), however this seems very clunky in a modern internet. For example I would have to list every country in Europe, even though they all pay in euros, and all have the same delivery price; in effect I'd be creating x50 extra identical pages for each product (as there are around 50 countries in europe)

Any suggestions?

  • 1
    I wonder if there was a more regional targeting as opposed to countries. I know that geo-targeting is by country or language, but I wonder if there was a simple way to target more toward currency. That would be more ideal. If you were to stop your currency by IP address, you could simply do what others do, listing prices in several currencies. I would make the most important to you the first one listed. It may be that you can list them in a more sentence style format using commas and they will all appear in search. Who knows? You can create a temporary product and use Fetch as Google in WMT.
    – closetnoc
    Mar 22, 2015 at 19:25
  • Thanks @closetnoc; there is a button to change currencies, but design wise it doesn't fit in very well to list the 3 currencies we offer; I suppose we could list them in hidden elements and let javascript handle the change of currency tho. Good idea about WMT, I'll have a play. I think for now I may exclude the setting of currency by IP for the crawlers so that they see our primary currency; It's a nice feature for users however.
    – Radderz
    Mar 23, 2015 at 13:26
  • The idea of the currency by IP is a damned clever one! I can see how you do not want to change your feature. I like to experiment and use GWT to help me. I do not like to make a pest of myself, but sometimes it is necessary.
    – closetnoc
    Mar 23, 2015 at 14:21
  • You could try rendering out all currencies in the mark-up and then show/hide the relevant ones through JS or CSS (I.e. Set a wrapper class based on region and then wrap each currency in a span so you could say .gb .usd {display: none;} to hide all US$ span elements Mar 26, 2015 at 21:11
  • @Zhaph-BenDuguid Yes this could be done; but the problem is with the crawlers not the users. It's getting the search engine to show the correct local currency within country searches, and it looks like they won't be intelligent enough to show the correct price. They will either show the one that isn't hidden, or all 3. I may well give this option a go and try to tweak to get the best results, but it's not going to be perfect :|
    – Radderz
    Mar 27, 2015 at 13:00

2 Answers 2


Hate to disagree with the accepted answer, but why not use the offer schema type so you are not messing with CSS for data?

<div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
    <meta itemprop="price" content="229.95" />
    <meta itemprop="priceCurrency" content="USD" />
<div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
    <meta itemprop="price" content="180" />
    <meta itemprop="priceCurrency" content="GBP" />
<div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
    <meta itemprop="price" content="400" />
    <meta itemprop="priceCurrency" content="AUD" />

I also think this parses better from a code stand-point as you can also bake in additional information for search engines and parses such as elligibleRegion, seller, warranty info etc.

On display; if this becomes an issue, simply allowing the user to choose from a drop-down (can optionally be marked up separately using these as a data-source). Also allowing saving of selections with account data is probably a good option; or at the least appending a query string to the url. Combining these should be enough to show the relevant currency for humans.

I would not use CSS, but it's not wrong to use it, it's a design choice. Potentially JavaScript would be a good candidate for those concerned about logic load on their sites; but it is very important to remember only use JS presentationally. No form inputs or user-data other than quantity and product-ID should be decided by JS so that your site remains usable in a non-JS state. Potentially scripting logic on the server for those concerned with reliability and consistency is the ideal, but the schema markup included is I think very powerful for use even in static content and simple websites.

  • 1
    Yes agreed; however the accepted answer did use the offer schema, just you've done it in a far more elegant/non-intrusive data orientated way. I think this is useful, and a good starting block. As you say, JS and CSS can reference and display to the user the appropriate data based upon their preference or location, and all the data is available for the search engines to have a fest over :) - Thanks for your response, Radz
    – Radderz
    Feb 2, 2016 at 14:05

Google's "International" section of their Webmaster Tools talks about "Locale-aware crawling by Googlebot". This appears to be a relatively new (seems to have been announced in January 2015), and is fully automated by Google (emphasis added):

Today we’re introducing new locale-aware crawl configurations for Googlebot for pages that we detect may adapt the content they serve based on the request's language and perceived location.

They are using both geo-distributed crawlers as well as the accept-lang headers, which should help, but as they haven't said where these new IP's are coming from might still miss the UK.

One thing that might also help is the use of micro-data on your site.

This would allow you to serve all currencies in your markup, hide those that weren't valid for the current user/ip through CSS/JS and still have Google understand what you're doing:

<div class="curr-gbp" itemprop="offers" itemscope itemtype="http://schema.org/Offer">
  <!--price is 1000, a number, with locale-specific thousands separator
      and decimal mark, and the $ character is marked up with the
      machine-readable code "USD" -->
  <span class="usd" itemprop="priceCurrency" content="USD">$</span>
  <span class="usd" itemprop="price" content="1000.00">1,000.00</span>
  <span class="gbp" itemprop="priceCurrency" content="GBP">&pound;</span>
  <span class="gbp" itemprop="price" content="750.00">750.00</span>
  <span class="aud" itemprop="priceCurrency" content="AUD">$</span>
  <span class="aud" itemprop="price" content="1500.00">1,500.00</span>

You set the class on the containing div to the currency you've selected for the user and then hide the other options through CSS:

.curr-gbp .usd, .curr-gbp .aud { display: none; }
.curr-usd .gbp, .curr-usd .aud { display: none; }
.curr-aud .usd, .curr-aud .gbp { display: none; }

Google should then recognise the mark-up and display it as appropriate in its listings.

  • 1
    Thanks, I'll give this a go. My micro data doesn't implement multiple currencies, I didn't realise you could do that! I'm glad Google has announced progress on international searches, I'm hoping I will notice difference in the behaviour within their April update.
    – Radderz
    Mar 27, 2015 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.