Just a quick post today based on a random discovery that I made over the weekend…
I was checking a SERP on behalf of my parents’ company (IT recruitment sector) from my phone simply because I didn’t have my laptop or tablet to hand. A search for "web developer job cardiff" showed the following:
Two things struck me as odd about the first result, which is first on both mobile and desktop searches. Firstly, the top result isn’t labelled ‘Mobile-friendly’ (any SEO who’s not been living under a rock will know that this is big news at the moment), yet it’s ranking above two results that are. Secondly, having been on Indeed.co.uk’s website before, I was convinced that it was mobile friendly – so I clicked (or tapped) on it, and – as a matter of fact – it is:
So… what’s going on here?
Let’s take a closer look at the SERP:
Notice how the label next to Indeed.co.uk’s result shows ‘Jobs 1 – 10 of 370’ instead? I have a feeling that this rich snippet is overriding the ‘Mobile-friendly’ tag for this result – i.e. that Google is choosing to show the former instead of the latter (even though both are true)… which isn’t good for Indeed.co.uk (more on that below).
I thought that maybe this was a one-off error, so I found another result with the same issue. For the same keyword, the 6th result (on both mobile and desktop) is this page of Jobsite’s website.
…Which is Mobile-friendly, as you can see here (results in Google’s Mobile-Friendly Test tool) and below:
This is probably an automated design consideration on Google’s part. Showing both ‘Mobile-friendly’ and ‘Jobs 1 – x of y’ for both results would probably make each of the results look a little ridiculous, so it’s opting to choose the latter over the former.
While it doesn’t seem to be affecting their rankings in mobile because Google does still consider them mobile-friendly (as mentioned above, they rank as strongly on mobile devices as they do on desktop), the problem here is that as searchers become more attuned to the recent changes and decide to show preference by clicking/tapping on results labelled ‘Mobile-friendly’ compared to those that are not, Indeed.co.uk and Jobsite could see less of a click-through rate from searches from mobile devices even though they are mobile-friendly.
What’s worse is that the ‘Jobs 1 – x of y’ label doesn’t look like it’s been implemented purposefully (e.g. via Schema.org or something similar), so it doesn’t look like there’s an easy workaround for the two sites to get Google showing preferences to the ‘Mobile-friendly’ tag instead. The results for Indeed.co.uk and for Jobsite for their respective pages in the Google Developer Testing Tool (used to test and check rich snippet implementation) do not show that these have been implemented in this way from what I can see. I did wonder if it might’ve been due to pagination implementation instead (i.e. rel="next" & rel="prev"), but Indeed.co.uk isn’t using it and Jobsite actually looks like they might’ve implemented it incorrectly. So it looks as though Google’s simply noticing the count on each of the pages and adding the rich snippet itself based on that. With this in mind, the only solution that I can think of for either site is to remove those counts, which could negatively affect each site’s UX. But after all, they shouldn’t have to make changes to their websites worsening the UX in order to get Google to show something else instead – surely that’s against what Google wants websites to do?
It’s still very early days for the ‘Mobile-friendly’ tag – having only launched last week – so maybe this has been something that’s been overlooked by Google’s engineers and it’ll be rectified soon. In the meantime however, unless searchers actually click onto Indeed.co.uk’s and Jobsite’s results, they may think that they’re not mobile-friendly websites…
If I’m missing something (I could very well be!) or if you’ve noticed something similar with the same rich snippets or even other rich snippets then please drop a comment below or tweet me with info.
UPDATE: Read Grant’s comments below for some interesting insights straight from Google’s mouth (so to speak)…