Managing localized blog posts for hreflang

We have had increasing requests from clients to help them deploy hreflang on their blogs.  Nearly struggle with identifying and setting the alternate language versions of each post. This challenge is often found with decentralized architecture, with some setup on subdomains and others as folders and where markets do not have alignment on a content localization process.

If you have a uniformly structured blog in the same CMS with the same URL pattern on WordPress using WordPress Multilingual (WPML), this process is handled automatically through the parent/child relationship of the language versions.

Those with blogs managed across multiple ccTLDs with different structures use the default title as the URL format, creating unique URLs. This process becomes nearly impossible to manage.

For example, a CPG brand with 67 sites that all had blogs managed independently by the markets.  One of their SEO agencies identified multiple articles for Australia that were being cannibalized by other English markets. The company used HReflang Builder for the brand sites and wanted to use the same solution for the blog pages. The Australian blog posts were primarily cannibalized by the US, UK, and India (all English). They assumed these would all match since they were English but that was not the case. Picking twenty non-Australian pages with the most views/clicks in Australia, they tried to map the alternate versions. All market versions of the same article had different URLs and titles that made filtering or vlookup a challenge.

Method 1 – Translation Tracker (Google Sheet or Intranet)

This has been one of the most common methods companies have adopted to manage the variations.

This option only requires a Google Sheet with the initial or origin URL, and as markets choose to localize it, they add their URL to the tracker. With all of the URLs in the same row, you can use many of the free hreflang tag tools or import this file directly into Hreflang Builder’s Mapping Builder. This approach requires markets to use the worksheet.

Method 2 – Custom Meta Tag

Another method you can use is to leverage a custom meta tag with an article ID. You can then use your favorite SEO spider to find all pages with Article_ID, or whatever name you give the field, and then this will allow you to group all of the blog posts with the same ID.

Using the custom tag function in WordPress you can add a custom meta tag to each post. If each language version of that post uses the same Article ID, you can match those URLs. With Hreflang Builder, we have a feature where we will ping each page, extract that custom ID, and map all pages with the same ID as alternates.

We suggest you add a placeholder when you create the field and remind users that they need to change this to match the primary article ID. You can run a crawler to check for posts where this is missing and task the markets to fill it in.

Method 3 – Ad Hoc Mapping

You will need to do this if you don’t have any system in place. Using either of the above methods at any point in the process starts the organizing process. If you don’t have a method, you will need to ask someone in each market to try and align all of the alternates in each market.