Welcome to the Q&A Forum

Hi Dimitri,

You're most definitely right in your assumption that this is incorrect. Those are not even properly written hreflang tags, and are therefore useless.

The purpose of hreflang is to help search engines determine which language version of an otherwise duplicate webpage should be served to a user in a particular geographical area. Therefore, each individual hreflang tag includes both a country and a language. For instance, if you want users finding you through search in the US to be served the English language version of a webpage, the hreflang tag would be as follows:

However, if you wanted your users in Canada to be served the French version of a webpage (if it's targeted at a Quebecoi audience for instance), the hreflang tag would be as follows:

I don't think your current hreflang tags are damaging you as they're incorrectly formatted and probably therefore disregarded, but you should at the very least remove them until they've constructed an accurate hreflang set. How many languages is your site in?

Hope this helps!

Hi all– I've legitimately never seen this before, in any circumstance.

I just went to check the google webcache of a product page on our site (was just grabbing the last indexation date) and was immediately redirected away from google's cached version BACK to the site's standard product page. I ran a status check on the product page itself and it was 200, then ran a status check on the webcache version and sure enough, it registered as redirected. It looks like this is happening for ALL indexed product pages across the site (several thousand), and though organic traffic has not been affected it is starting to worry me a little bit.

Has anyone ever encountered this situation before? Why would a google webcache possibly have any reason to redirect? Is there anything to be done on our side?

Thanks as always for the help and opinions, y'all!

Hi all!

This is a weird one that I've never encountered before.

So basically, an admin granted me search console access as an "owner" to the site in search console, and everything worked fine. I inspected some URL's with the new tool and had access to everything. Then, when I realized I had to remove certain pages from the index it directed me to the old search console, as there's no tool for that yet in the new version. However, the old version doesn't even list the site under the "property" dropdown as either verified or unverified, and if I try to add it it makes me undergo the verification process, which fails (I also have analytics and GTM access, so verification shouldn't fail).

Has anyone experienced something similar or have any ideas for a fix? Thanks so much for any help!

Thanks very much for your response. You are exactly right about the travails of the multiple properties, and I hadn't even thought about how the new domain level access should handle the multiple versions of each site (I'm still used to having to verify four separate properties).

In the end, you were exactly right; I just had to FTP the verification file once more and it worked immediately.

A question, though: if you were trying to verify a non secured protocol (http://) of a site that is https://, and you were for some reason unable to verify through GA or GTM, wouldn't uploading a verification file automatically create a secured protocol and therefore be invalid for verification? This is (thank goodness) purely theoretical, but it seems as though it would be a rough task which I'm sure happens periodically.

Thanks again for the insight. You were a great help!