In a perfect scenario, the organization deploys a hreflang solution for all sites within a brand family and deploys hreflang for them simultaneously. Given the complexities of deploying hreflang at an enterprise level, most organizations should consider a phased roll-out plan focusing on where the problem is the most acute and/or what they can implement quickly.
The primary benefit of using hreflang is to remove any ambiguity related to where a webpage is targeting. Declaring a webpage in the English language for Great Brittian or in French for France tells Google it is truly unique helping ensure it is indexed and presented to the local market. This is why we recommend using the following steps or phrases when deploying hreflang so that you can get the most benefit as quickly as possible.
With this phase, the deployment will focus on a list of priority URL pairs that have identified cannibalization problems today. For many companies, this can also work as a proof-of-concept exercise to demonstrate the benefits of hreflang. By focusing on a small set of URLs that have known problems, immediate fixes can be realized while refining the process for a larger deployment.
No matter which method of deployment you choose, you can deploy this potential fix quickly using Hreflang Builder. The system only requires the cluster of URLs, and a mapping table, if needed, to be loaded in Hreflang Builder. The system can produce a set of hreflang XML site maps the team manually loads to the server and submit to Google.
Most often, cannibalization is escalated when identified in key high-traffic or revenue markets, specifically the US, UK, and Australian markets. With this deployment approach, the team identifies those key market pairs, such as UK and US, then deploys the solution to eliminate the cannibalization for those key markets. This phrase 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 pages that were previously identified.
Most SERP cannibalization occurs across the same language pairs, specifically with languages with multiple markets, like English, Spanish, and Arabic.
With this option, the team would deploy a full hreflang build for all brand-family sites in the same language. This is often an extension of Option 1 or 2. In many cases, same-language sites use the same URL structure, especially if localized URLs, making them 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 it solves the problem for a wider set of URLs. It is key to deploy hreflang for same-language home pages, products, and key content pages that may seem like duplicates if Google cannot identify them for a specific market.
With this option, the team would deploy a full hreflang deployment for all brand-family sites using the desired hreflang method using the organization’s available technology or Hreflang Builder then iterate improvements over time. For many companies, this gets significantly more pages, especially all home and key category pages deployed. This approach can often break through the perfection paralysis that bogs down many hreflang projects.
Don’t deploy anything incorrectly, such as invalid country or language tags or assuming every page exists in all markets. Not having every page aligned in the first few launches is fine as long as there is efforts for expansion and improvement.
This phase can be somewhat manual, and over time with the improvements, it will move to a fully automated system. The main benefit of this approach is it gets the maximum number of countries and pages deployed and allows all markets to start benefiting. It can also showcase problems with the process and underlying infrastructure that need to be changed to ensure ongoing scale and success.