Phased Hreflang Deployment

Last week, I received an email from a prospect saying they were postponing their hreflang project as it was deemed too complex. The project definition required them to deploy hreflang for all pages across nearly 100 market websites. Due to the complexities of their website infrastructure, the team had become overwhelmed. They struggled to map all the alternate pages since none of the site structures matched the diversity of produce offerings in each market. The project had a fixed timeline for implementing a solution, and he did not believe the executive would allow anything other than full implementation. He planned to let the time run out and not do anything. That is an option if you can get away with it.

We see this “perfection paralysis” in many projects, where those who developed the plan may not have any insight into the complexities of implementation, and the teams may be nervous to push back on the approach. I suggested that rather than do nothing, implement a phased roll-out focusing on where the cannibalization problem is the most acute and/or what they can implement quickly.  

These phases below can be deployed relatively easily using hreflang XML sitemaps and cross-domain hosting. I will post another article explaining how you can implement this methodology that may help you break the logjam.   

Phase 1 – Solve Acute Cannibalization Problems

This initial phase focuses on a simple list of priority URL pairs identifying cannibalization problems today. These are the URLs for which some executives have complained that another market’s website was ranking instead of theirs or for which the SEO team has reports showing incorrect ranking. For many companies, this can also work as a proof-of-concept exercise to demonstrate the benefits of hreflang.

Focusing on a small set of URLs with known problems can allow immediate fixes while refining the process for a larger deployment. For this phase, you can leverage hreflang XML sitemaps, which allow you to quickly build the hreflang cluster and load the XML sitemap(s) to the server for rapid indexing and results. Keep what is included simple without X-default and clones of URls for language or market expansions.

Phase 2 – Solve for Key Site Sections

In this phase, the team deploys a hreflang build for crucial site sections, including home pages, common products, and key cross-market content pages. Home pages are relatively easy to map as they follow a similar URL structure. Key categories can also be mapped from main menus since they occur across most, if not all, markets.  Once the initial build is live, the team can expand markets and implement methods to map URLs beyond this initial set.  Unfortunately, some companies mistakenly stop at this phase. Our research found that 40% of companies only implemented hreflang on home and category pages under the incorrect assumption that these settings trickled down across the site.  The main benefit of this approach is that it solves the problem for broader category searches and those for the company name and gives you better insights into the complexity of the URL structures in all markets.   

Phase 3 – Solve for Key Markets

Traffic cannibalization is often escalated when identified in key high-traffic or revenue markets, specifically those in English like Australia, Canada, UK, and US markets.  It can be the most acute with same-language neighbor markets like the US and Canada or Germany and Austria. Same-language markets often have the same URL path structure, which makes mapping alternates easier. With this deployment approach, the team identifies those key market pairs, such as Canada and US, then deploys the solution to eliminate the cannibalization for those key markets.  This phase is another great proof of concept approach as it is a larger set of pages and can have a broader impact than just a few previously identified pages. 

Phase 4 – Solve for Same-Language Pairs

Most SERP cannibalization occurs across the same language pairs, specifically with languages with multiple markets, like English, Spanish, and Arabic.   This happens because Google encounters the same or similar page, may consider it a duplicate, and may exclude it from the index. Using hreflang gives the page the purpose of targeting a specific language region and eliminating this perception of duplication.

In this phase, the team deploys a hreflang build for same-language home pages, common products, and key content pages. As noted previously, same-language sites often use the same URL structure, making it easier to map the alternates. Once the initial build is live, the team can expand markets and implement methods to map URLs that are not consistent. The main benefit of this approach is that it solves the problem for a wider set of URLs. 

Phase 5 – Build Most and Iterate

With the other phases in place and hopefully several success stories, the team can now deploy a larger-scale hreflang deployment for all brand-family sites. Don’t deploy anything incorrectly, such as invalid country or language codes, missing return tags, or restrictive X-Default, nor assume every page exists in all markets.   

Not having all pages included in the first few launches is fine as long as there are continued efforts for expansion and improvement. However, don’t deploy anything incorrectly, such as invalid country or language codes, missing return tags, or restrictive X-Default, nor assume every page exists in all markets.

This build-most and iterate phase can be manual, but with the upgrades, it will move to a fully automated system over time. This phase leverages previous learning and deploys more countries and pages, realizing more significant traffic. Due to the scale, there will be issues with the overall process and underlying infrastructure, which must be addressed to ensure ongoing scale and success. 

The main benefit to a phased approach is it allows you to do something constructive while starting to solve the cannibalization issue where it has the most attention, acute need, and greatest revenue capture opportunities. Unfortunately, there is rarely a one-size-fits-all approach to hreflang. For many companies, this stepped approach will typically break through the perfection paralysis that bogs many hreflang projects.  This is one of the reasons we created Hreflang Builder, which made it easy to iterate and manage your hreflang deployments.