I was recently contacted by a client for an online consultancy because his online store had stopped indexing in Google and was losing ALL his sales in a matter of days, going from several thousand a day to zero.
Table of Contents
The SEO problem
As always when it comes to SEO, I first checked the robots.txt file and found a line like this:
Disallow: /?v=*Code language: HTTP (http)When I checked the Google Search Console of the site I found, as it was logical, that all URLs were blocked by the robots.txt file, so that everything previously indexed, was now disappearing at full speed from Google search results, and when before they had lots of products as the first organic result, every day they were sinking deeper in the SERP, with a tendency to disappear altogether.
I asked why they had added that line and they told me it was because their URLs had always ended with parameters like store.com/?v=a1234b56 or similar, totally random, and at one point they considered de-indexing all URLs that ended that way so as not to confuse Google with URL parameters, following their “guidelines” on the matter.
The problem was that ALL THEIR URLS HAD PARAMETERS of that type and, consequently, they deindexed the whole site.
The solution seemed simple: Remove the line in the robots.txt file that was causing the problem. And that’s what I did. We resubmitted the robots.txt to the Search Console and, fortunately, in less than 24 hours the new one was already available, Google restored the previous indexing status in a matter of hours and the orders came.
But the question remained as to why all the URLs of the online store, created with WordPress and WooCommerce, systematically added these parameters to all the URLs of the site.
There would not be a serious SEO problem keeping the parameters in the URLs, at least not as serious as deindexing the whole site, but better if I investigated more why those parameters were being added, and if they could be removed without problems.
Why does WooCommerce add parameters to URLs?
I always have several test installations, of WordPress, of WooCommerce, with Elementor, with Divi, with everything, to test and detect problems, and reviewing the demos, I found one of them that also added this type of parameters to the URLs of the online store.
And the thing is that it didn’t add the parameters only to the product pages, it added them to all the URLs of the site, no exceptions.
As you should always do in these cases, I deactivated all plugins except WooCommerce and switched to a default WordPress theme and the problem persisted, so it must be something in WooCommerce.
The mystery should be in some WooCommerce configuration and the only difference between this test site and the rest, in which it did not happen, was the following setting:
This setting is in WooCommerce → Settings → General → Default customer location, and allows you to choose from several options whether and how to try to identify the location of the customer visiting our store before entering their address at checkout.
This is useful to, for example, show customers a calculation of taxes or shipping costs according to their country, although in reality, it would be with the IP declared by their browser.
Should I geolocate customers?
Personally, I never recommend geolocation, for several reasons, but mainly because it is usually not real, since the location from which the customer connects does not necessarily coincide with his billing address or residence, among other possible problems.
How to remove parameters added at the end of WooCommerce URLs
That said, I found that changing that setting to any of the other options (No Default Location, Shop Base Address, Geolocate) made the URL parameters disappear.
Once this was done, the problem was solved and the URLs were cleaned, now without strange random parameters.
What do these parameters in URLs mean? What do they do?
In case you were curious why WooCommerce adds those random parameters at the end of the URLs when you choose the option to geolocate with page cache support, let’s see the reason, totally logical and reasonable, by the way.
The option to geolocate customers to show them tax and shipping calculations before having to enter their billing address was introduced in version 2.3 of WooCommerce, but it was soon found that this option was useless when the site had some page caching system active, and almost all of them do, simply because it’s convenient, because it speeds up the loading of the online store.
It turns out that on these sites with page caching active, the geolocation failed all the time, because the pages were not really updated on each visit, but the cached version was displayed, offering tax and shipping calculations that did not adapt to the current customer, but to the version stored in the cache.
So in version 2.4 of WooCommerce this geolocation setting was added, but now compatible with sites that had some page caching system active.
The new setting worked like this when activated:
- When a customer visits a page on the site, a background AJAX call is launched that geolocates that user via AJAX and returns their location.
- The returned location is compared to the user’s known location. If the location is not yet known, or the location has changed, the page redirects itself with an additional query string. e.g.,
v=a123b456This is a parameter based on the user’s location. - The parameter, like any other parameter starting with
?at the end of a URL (a very common trick to bypass the cache of a page), causes the cache to be invalidated: The new page (with the query string) will be cached separately.
Thus, if a customer from whatever country visits a page, he will get a query string (parameters) based on that country – he will only see cached versions of pages from other customers from that country. This solves the caching problem, without the need to disable it completely.
The downside of this is the extra AJAX request per page, however, this is necessary, as without this there would be no geolocation on a cached page.
Should I leave those parameters active at the end of the URLs?
If, despite what I said above, you still want to geolocate your customers, or you need to do it for some reason, my advice is to use the “Geolocate (page cache compatible)” setting and assume that the parameters will be added via AJAX calls to your URLs.
It’s less optimal for the loading speed and resource optimization of your online store pages, but at least the geolocation will be tailored to your visitors, instead of driving them crazy with cached versions of other visitors.
Isn’t it an SEO problem to leave those parameters at the end of URLs?
If you use WordPress, even if you do not use any SEO plugin, it is no problem to generate these parameters at the end of the URLs because WordPress automatically declares the correct canonical URL, so it will always be clear to the search engine bots which URL to index: The canonical.
Another thing is the slowing down of the web, associated with the AJAX calls that WooCommerce must make to generate the query strings, which by slowing down your online store can have an adverse effect on the user experience and, consequently, on SEO.
As with everything else, you have the information, the decisions are up to you.
