Why are “srsltid” URLs ranking in Search? Is it related to Google’s August 2024 Core Update?

Starting around the beginning of August 2024, many Shopify storefronts and SEO stakeholders started noticing a strange “srsltid” query string parameter appending to the product and collection URLs appearing in Google Search results and position tracking reports. This ongoing issue has made it difficult to track performance for eCommerce URLs in SEMRush and other position tracking softwares, leaving many to speculate that the issue might be related to Google’s August 2024 core update.

If you’re one of the many store owners with SRSLTID links ranking in Search, rest assured that you’re not the only one that’s confused. The preponderance of these mysterious query strings is alarming, our SEO and analytics teams here at BlueSwitch have been closely monitoring the situation as it unfolds.

Keep reading to learn what’s causing “srsltid” queries to appear at the end of your product and collection URLs, what effect this issue might have on rankings and SEO, and what you can do about it.

A screenshot from a SEMRush position tracking report which shows a number of "new" Merchant Center query string URLs appearing in Search rankings

What is a query string?

A query string is a segment of a URL that’s used to append additional contextual data onto the end of a traditional URL. Query strings are tacked onto the end of standard URLs, beginning with a ‘?’ question mark, and followed by an alphanumeric string. In the context of eCommerce websites, query strings are used to organize product parameters and track which attributes and combinations of attributes are driving traffic on your site.

Query strings are crucial for organizing tracking and analytics data

Query strings are used to create URL paramters for tracking, sorting, searching, identifying, paginating, translating, and filtering the various pages of any website. On Shopify and Shopify Plus, query strings are used to organize product variants like size and color (example.com/t-shirt?variant=9999999), and to identify specific site-search parameters. On analytics platforms like GA4, query strings can be used to track the traffic coming from advertising campaigns (example.com/t-shirt?utm_source=linkedin&campaign-id=99999).

The “srsltid” query string is automatically generated by Google Merchant Center

A quick Google search revealed that the “srsltid” string is specific to Google Merchant center, a fact which has been verified by documentation provided by Google. So according to Google, these query strings are completely normal, and are expected to appear on Merchant Center links when the “auto tagging” feature is turned on.

Why are ?srsltid query strings appearing as “new” URLs in my analytics reports?

So now we know where those “srsltid” parameters are coming from, but what we don’t know is why these mysterious links are suddenly showing up in SEO tools like SEMRush, Ahrefs, and Moz. Not only are these URLs being displayed in tracking tools, but it seems that they’re also being indexed by Google, and in some cases, they’re even ranking for our target keywords.

Before August of 2024, it was not a common occurrence to see ?srsltid= parameters appear in tracking software. These links were used by Merchant Center to internally track product clicks, but they weren’t displayed anywhere except in the user’s navigation bar.

Suddenly these ?srsltid= links started appearing in SEMRush Position Tracking as “new” pages that were ranking for our most prized keywords

Then in August 2024, the SRSLTID links suddenly started appearing outside of Google Merchant Center. Here at BlueSwitch, we first noticed them appearing in our SEMRush Position Tracking reports, then the query string URLs started replacing our canonical URLs in Google Search results. That’s when I decided to take a closer look at the data, and honestly, I was a little freaked out by what I saw.

By all appearances, it seemed that these query URLs were being indexed by Google as regular pages. Not only that, but suddenly these ?srsltid= links were appearing at the top of our search results and ranking for our most prized keywords, and pushing our canonical URLs down in rankings.

Query links aren’t supposed to be indexed, and they aren’t supposed to rank in Google Search

Merchant Center links ranking in organic search results? Could this be true? If it were true, then it would be problematic for a number of reasons. For one, if Merchant Center links are being indexed as the canonical versions of our pages, that would cause a massive shift in within analytics, artificially inflating the rate of traffic appearing to come from Google Merchant Center, which appears in GA4 channel reports as “Organic Shopping.”

Additionally, if these query links were ranking for our best keywords, then what happens to the rankings for the canonical URL? Are all of our highest ranking URLs now going to have 80 characters of gobbledygook tacked onto the end? What will that do to user experience? What would be the longterm effects of such a shift? Can we make it stop? Do we have to turn off auto-tagging in Merchant Center? Do we have to start MANUALLY tagging variants?

I told you I was freaked out. I still am freaked out, actually, but at least now I have a better idea of what’s going on here.

Have no fear, it’s Reddit to the rescue!

As our SEO team’s collective panic attack subsided, we started digging a little bit deeper into the search results, where we turned up a Reddit post from a user named HasKhachatrian that was having the same experience as us. Okay, I thought, this is good. It’s not just happening to our clients.

I can’t tell you how relieving it was just to see that another user out there on the interwebz was having the same panicked reaction to this issue (okay, well, maybe HasKhachatrian wasn’t freaking out the way I was, but still).

Here’s the post:

At the time of this writing, there was only one comment on the post, a Redditor named crepsucule offering a simple theory that put things in perspective:

Let me clarify. Crepsucule’s theory reminded me of something that I’d observed and discussed in recent July-recap reporting calls with our SEO clients. You see, right around the end of July 2024 (July 27th, to be exact) something strange started happening with our keyword rankings.

Namely, lots and lots of pages started to decline in rankings—and by decline, I mean the rankings were obliterated, totally destroyed, vaporized—however, when I went to the front end of Google and searched those declined keywords, I noted that our clients’ pages were still ranked in the top spots.

But here’s where it gets interesting, because when the rankings started to decline, I opened a guest window in Chrome, and started Googling all of my clients’ declined keywords. Can you guess what happened on the front end? NOTHING! Nothing happened.

At the time, I figured this false positive (or false negative, actually) was an issue with the Google Rankings API that SEMRush ties into for Position Tracking reports. SEMrush says my rankings are dropping, but my eyes tell me that all the right pages are still ranking where I expected. That has to be an issue with the Rankings API, right? RIGHT??

What a relief, this massive decline in rankings was no big deal, since the data in my reports didn’t match the SERP I was witnessing on the front end. We told our clients not to worry about it, and that everything would likely normalize before our August reporting calls. Well I hate to be the bearer of bad news, but the state of Google Search right now [at the end of August] is far from what I would call “normal.”

As July faded into August, the rapid decline of keyword rankings started to taper off, and we started to see those declining keywords pull and about-face and start increasing in rankings. I was relieved to see those declined rankings starting to increase again, but when I saw Crepsecule’s comment on the Reddit thread, I went back and took a closer look at those newly-increased rankings. That’s when I noticed something strange…

It wasn’t my canonical URLs that were moving up in the rankings, it was the SRSLTID query string URLs. Suddenly, all these Merchant Center links were skyrocketing in rankings at the same time that the rankings for our canonical URLs started dropping off the face of the earth. So while it was still technically the same PAGE that was ranking for a given keyword, the ranking URLs had changed over to these srsltid-links.

What could cause a massive drop in rankings for historically high-ranking URLs, and at the same time cause the query-string versions of those URLs to increase in rankings?

Our SEMRush position tracking software telling me that a Merchant Center query string URL is the #1 ranked result for our most important keyword, which turned out to be incorrect.

Spoiler Alert: The August 2024 core update has arrived

Well, if there’s one thing that I know about SEO, it’s that when inexplicable things are happening in the SERP that involve multiple Google platforms, it can only mean one thing: CORE UPDATE INCOMING.

So now we had a working theory, that the declining rankings for canonical URLs, the increased rankings for Merchant Center URLs, and the indexing of these mysterious SRSLTID query links are all connected through a pending core update to Google. So naturally, I did the only thing that makes sense, I Googled “is there a core update in August 2024?”

Well I’m happy to report that Google has confirmed today [August 15, 2024] that there is indeed a core update happening (I love being right). Unfortunately, Google didn’t give us a whole lot of useful information about the core update, and they didn’t mention the Merchant Center query string issue at all, but they did give us something. This is what Google had to say about the August 2024 core update to Google Search:

Today, we launched our August 2024 core update to Google Search. This update is designed to continue our work to improve the quality of our search results by showing more content that people find genuinely useful and less content that feels like it was made just to perform well on Search.

This latest update takes into account the feedback we've heard from some creators and others over the past few months. As always, we aim to connect people with a range of high quality sites, including small or independent sites that are creating useful, original content, when relevant to users' searches. This is an area we'll continue to address in future updates. This update also aims to better capture improvements that sites may have made, so we can continue to show the best of the web.

Note the line in the second paragraph that mentions small or independent sites. As it turns out, all of our client sites that experienced a sudden decline in rankings could easily fit into that category of “small or independent sites that are creating useful, original content,” so it makes sense that this current core update would throw our rankings into chaos, because the target of the change are websites similar to our clients’.

Editor’s Note: Since the time of this writing, Google has vaguely acknowledged an ongoing issue with rankings that is related to the August 2024 core update. On the Google Search Status Dashboard, they claim that the rankings issue was resolved on August 20th, however, many clients and SEOs have reported ongoing issues with rankings and SRSLTID query strings. We will update here as news develops.

In all likelihood, this issue with srsltid links is a glitch in the matrix core update that Google is actively working to correct.

It’s highly unlikely that Google intended to “swap” the rankings of canonical URLs with their query-stringed relatives. It just doesn’t make sense to do it that way.

So, while it’s pretty frustrating to see all that red in our position tracking reports, and to have inaccurate data flooding our Google Analytics pageview reports, it’s a relief to know that these issues are not being caused by something that we did or didn’t do correctly.

So what now? How do we fix this issue?

Such is the case with most anomalous SEO phenomenons, there are slew of SEOs out there offering advice on this issue. Some folks are suggesting that we turn off auto-tagging in Merchant Center, or use 301 redirects to push users to the “correct” version of our URLs, or create Robots.txt commands that block crawlers from query strings that begin with SRSLTID. These are all valid strategies, but since we don’t really know for sure what’s causing this issue, adopting these strategies prematurely could have unintended consequences that are potentially more harmful than the issue they’re meant to resolve.

Here at BlueSwitch, we’re taking a “wait and see” approach to the SRSLTID issue. We still don’t really know for sure what’s going on here, so taking dramatic action could do more harm than good. SEO is a long game, and patience is one of the preeminent keys to success. At this point, we feel the best available strategy is to wait for Google to straighten this mess out so we can get back to business as usual. While the situation might not be ideal, at least now we know what’s happening, and why it’s happening (to a degree), which allows us to plan and work around the issues as we wait for more reliable information to surface.

Here’s hoping that your team gets through the August 2024 core update unscathed, and with minimal pain and suffering in the SERP.

UPDATE 10/21/24: The issue seems to have been resolved?

Good news from the world of SEO! An examination of rankings and URLs this morning reveals that the SRSLTID query strings have started to disappear from Google Search results and rankings/position tracking software like SEMRush. Looking at other threads like this one on Reddit, it seems other folks are seeing the issue dwindling and “regular” URLs now ranking in SERP. In our own position tracking reports, we’re seeing that SRSLTID query strings have disappeared from the rankings. Breathe easy, folks, all is right with the world ;)

Want to know more about BlueSwitch SEO? Contact us today and schedule a discovery call! And don’t forget to mention how you found out about BlueSwitch (**cough** from this blog post **cough-cough**)