Being on WordPress, there are a number of ways in which I can implement Hreflang through plugins, easily.
The two market leaders for WordPress being PolyLang and WPML, but not everyone (and every platform) has it so easy, and for a number of online businesses there can be a number of obstacles and development issues when attempting to implement Hreflang through either the <head>, HTTP Header, or XML sitemap.
Working with a lot of large, established brands the common trends and general SEO obstacles exist – but on larger scales. One of the use cases that initially inspired this research was a large, international travel brand that is soon approaching it’s 50th year in business.
Being a relative household name, with a global presence and 15 international websites, the brand had never engaged with an SEO consultant previously and as a result had no Hreflang, and a lot of duplicate content/cannibalisation issues being caused by the alternate versions.
However, due to large legacy tech stacks running on… less than modern infrastructures, implementing Hreflang was an expensive (resource) cost.
Because of this, it was essential to find a solution to effectively bypass the legacy tech stack to implement what is essentially a foundation of international SEO.
The principle behind what we’re trying to achieve is the employment of code generation, which given a configuration, input data and a specific run-time, will generate a self-sufficient worker bundle that can be deployed with no DevOps.
Sloth is the development of a self-sufficient service worker bundle that can implement Hreflang tags into the <head> of a website, bypassing restrictions faced by legacy tech stacks, development restrictions, or time constraints.
Sloth however is and can be much, much more. Using the same principle of the HreflangSloth, the Sloth service worker bundle can be configured to:
Implement/override meta tags, such as robots, title, description
Implement/override canonical tags
Implement redirects between URLs and protocols
Collecting “log data”, by configuring the bundle to collect log requests and response codes
How To Do This: Hreflang Code
The below code snippet is an example of the configured code for Hreflang deployment through service workers:
The result of implementing this service worker, on the face of it when viewing through a browser is plain HTML in the <head>, however when you get a direct server response – the service worker hasn’t deployed and no Hreflang is present, as you can see from the below screenshot:
Going on the advice of Google’s John Mueller to test whether or not Google will be able to view the Hreflang in the rendered HTML, we used the Google Mobile Friendly test, which showed that the Hreflang is visible and being picked up by Google: