Alright! Let’s talk some more about hreflang tags.
Let’s get into the implementation of them. This is where a lot of the mistakes are made.
When implementing hreflangs, there are 3 places you can have them:
- Within the HTML <head> section of pages
- Within the HTTP headers
- Within the XML sitemap
The first option is not the best.
I like to sway clients away from this option because it causes a lot of issues in the long run.
This option is done on a per page basis. And as such, it’s more of a manual approach.
Because of this, there is plenty room for error.
If your ways of working, if your approach is not streamlined, your implementation will likely result in a lot of errors, a lot of issues to fix.
So I tend to only suggest this approach as a last result – a workaround.
The second approach – within the http header – is the less common one.
This is used for non-HTML pages – namely, PDFs.
As SEOs, we tend to focus on HTML pages.
If PDFs are ranking highly, as an SEO, we would want to appropriate the PDFs into pages – either existing ones, or entirely new pages.
So, you may find that SEOs are less interested in implementing hreflangs for PDFs.
Now, the third option, to implement your hreflangs within your XML sitemap, is by far the most popular and the best option – out of the three.
This is the ‘cleanest’ option out of the three.
Oh, and by the way, if you do not have an XML sitemap, you absolutely should create one.
No exceptions. Create one.
An XML sitemap informs search engines, like Google, of the pages on your website.
When submitted to Google, they use the information within it (or them – in the case of multiple XMLs) to find and crawl the pages on your site.
If you have an International website and have thousands of pages per locale, crawling pages can be quite a task for search engines.
Understanding the relation of pages across the locales is an even bigger task.
As a marketer, you want to make your website accessibility easier for search engine.
You want to make the understanding of your site by search engines, easier for search engines.
You want to make the crawling of your site easier.
And I use this word, ‘easier’, purposefully.
Making accessibility and understanding of your site, ‘less-easy’, is a problem.
It’s your problem.
Yes, it’s the problem of search engines but it’s also your problem.
You like the traffic you receive via search engines, you want to keep on receiving traffic from them? You’ve got to ensure you do everything you can to help them rank your site – highly, and in the case of an International presence, appropriately.
Including your hreflangs within your XML sitemap makes the implementation easier, and makes the readability, by search engines, easier.
As I said on the previous podcast, hreflangs are signals, not directives.
What you don’t want to do is leave it to Google to figure out which local version of your site is the correct one to show in the SERPs.
It’s a task they can, and will, get wrong, and it can, and will, cost you.
Before you implement your hreflangs, you’ll want to ensure you have it right.
You’ll want to ensure you can verify that it’s correct before telling Google about it.
You’ll want to ensure you’re not sending incorrect signals to Google.
Remember, hreflangs are signals.
If you’re giving Google this signal, and as such, are telling them to use it, the last thing you’ll want to do is confuse them with hreflangs that are incorrect.
Hreflangs are one of the most complicated areas of SEO.
It’s an area that you absolutely need to have SEO involved with.
It’s no good simply leaving the implementation to Devs.
Devs are not SEOs.
You cannot task them to think of SEO-related tasks.
Now, they implement SEO-tasks but shouldn’t be the ones thinking about what should be implemented for SEO purposes.
This needs to be created by SEOs – with SEOs and Devs then working together to implement the recs – in this case, the hreflangs.
Let me give you an example of why both parties are required for a project as such.
Let’s say you have a UK site and now want to scale to EU to cover that region.
You aim to target FR, DE and ES to begin with – and want to target the locale language in these markets.
You also want to target everyone else in the EU that speak English.
A Dev person would quite easily create directory folders for FR to target the French, DE to target Germans, ES to target Spanish people and EU to target English-speakers.
A Dev person would create a directory URL containing ‘eu’ in it.
From a Dev point of view, this isn’t an issue. It’s quite logical, actually.
From an SEO point of view, we would never suggest something like this for a directory URL.
We won’t even stand for it being approved.
You know why, right?
EU is a continent, not a country. You cannot target a continent in the URL.
You especially cannot target a continent in your hreflang tags implementation.
This is a mistake I see quite often.
It’s a mistake that sends incorrect signals to Google.
It’s a mistake that leads Google astray.
At best, it sends mixed signals to Google.
If you send mixed signals, as such, to Google, and you have a competitor that does not, who do you think Google is likely to rank higher in the SERPs…?
Having your hreflang tags implemented incorrectly can, and will, cost you.
