In the past few months, we have had a couple of clients that were successfully using HREFLang Builder migrate to internal solutions that resulted in significant errors and negative impact on the business. We took a deeper look at why these migrations were necessary and then why these internal solutions have failed. In all of the cases where the migrations were not preplanned, the reasons were either DevOps manding no outsourced solutions or new SEO agencies wanting to own the HREFLang for their clients.
The main reason the new internal solutions failed is the developers did not completely understand how HREFLang works and a complete lack of testing of the solution before it was implemented. While HREFLang is not really that complicated it is very detail orientated and we find a lot of people don’t pay attention to the details and make assumptions that Google can figure it out with partial implementations.
A couple of these cases were due to the DevOps managers not wanting anything outsourced. They had created custom CMS systems and mandated them to be used. The strangest of all was the cases is the one where there were already over 400 open dev tickets but the HREFLang implementation jumped to the top of the list – he just wanted it internal. There was no review or checking he had complete confidence in his coders and just launched it without telling anyone. What was frustrating to us is that for 4 years we offered full-service HREFLang Management to this client and had zero HREFLang errors and have generated tens of millions in incremental revenue since the correct page ranked in all markets. It was on the roadmap to implement HREFLang via the CMS once the new CMS was in place and all of the major tickets were implemented.
The Dev team deployed the new HREFLang solution from their in-house developed CMS and immediately we had errors.
They created a single XML file with all countries mapped to the main site but did not account for the requirement that they all must be mapped back to each other. This created “no return tag errors” for all of the counties. The errors went from 0 to nearly 12k shortly after launch until we removed their HREFLang file and the error started declining. They then added the mapping for all of the countries which created a 90 mb file which exceeded the allowable file size for XML so the errors stopped declining. The CMS created XML site map has been removed and we expect the errors to go back to zero.
We were able to make our case to revert back by showing the negative impact on the business. In the site impressions and clicks report from GSC we can see the number of impressions by other countries to the global site increased and clicks decreased due to the non-local content being presented. IT is obvious the wrong pages are showing in Brazil, Canada and Germany due to the poor click rate helping support the case for correcting HREFLang quickly.
In a second case, the DevOps team leader was also an aspiring Technical SEO and we worked relatively well with him with his team managing the implementation directly using HREFLang Builder. However, once John Mueller posted on Twitter that the HREFLang Element is the most technically challenging function in SEO, he told the team he must manage it personally and wanted an internal solution. The screen capture below shows his evolution and validates the complexity of HREFLang.
1. This is after we removed most of his HREFLand XML that had errors. There was nearly 100% error rate with the internal HREFLang XML so we pulled them down and you can see the errors started to decrease and we want back to our XML.
2. Not to give up and without telling anyone, he decided to put the tags into the page and it doubled the number of tags from 833k to 1.7 million in addition to adding 127 rows of extra code to the pages. The immediate decline in errors was due to us pulling our HREFLang XML since our mapping conflicted with his in-page tags as noted below.
3. Interesting collection of errors were created in his solution that shows why there needs to be collaboration.
For smaller sites we would suggest they keep the code in place and then correct the errors and remove our XML format. This allows them to integrate dynamically as pages are added or removed. In this case, since it represented 127 countries and the same number of rows we are able to make the case that it was better managed in XML format to reduce the code in the pages. This also helps us to monitor the indexing of the pages. They are in the process of removing the code from the page.
In a couple of other cases where an internal HREFLang magically appeared it was due to old tickets finally being implemented. In the example below, there were multiple tickets, one for an XML site map version and one to add to the page that was 3 years old.
The offshore Development team integrated HREFLang into a new deployment of AngualrJS in the data layer of the page. Unfortunately, since most of the SEO’s were only looking at “view source” they did not notice it in the data layer which is only visible using the Dev Tools Element view. A few months later, the internal team deployed a version using XML site maps generated by the CMS. Neither the internal team nor the SEO team was aware that these had been implemented. Beyond lack of communication, the implications did not match how they were mapping URL’s. The XML was using language mapping but the embedded version was using country and language mapping. Ultimately, both versions were ignored due to the conflict.
This is why we advocate having the SEO team as part of the weekly dev standup meetings so they would have heard that they were finally getting to this ticket and could have advised them and/or taken appropriate action. This was another case of a 100+ country implementation so we advocated the XML site map version keeping the language only tags since they could not map multiple listings and the sites were more language can country specific. In the end this worked out with correct automation.
Some of our best projects are with agencies managing HREFLang XML for their clients. We prefer to license HREFLang Builder and let the agency manage everything and only manage everything when there is not an agency or they are not interested in offering that service. The agency partner model works best since they are aware of all of the site changes and have access to rank reports and error reports. What is frustrating is when we have a solid solution in place and just needs care and feeding by the agency yet they want to move the client to their manual or Excel scripting version so they can charge for labor. It fascinates me the number of agencies that want to spend client resources manually developing HREFlang XML files rather than using an automated solution and spending that budget on something more productive for the client. We have shown the economics of outsourcing by the agency and also understand the politics of why they often don’t licesne software.
We have a case now where the client suggested to the new SEO agency they use our solution since the previous agency had not been able to implement an internal solution. We set up the demo and had a working XML in April but nothing happened. Fast forward to September and the client contacted us directly for a demo since the agency was not developing “their” solution quickly enough. The eCommerce Manager told us the lack of HREFLang was costing them about $5 million a month in lost revenue. This meant the agency cost the client about $30k in revenue. After seeing our solution the client told the agency to implement it ASAP despite the agencies attempts to delay implementation. In the end, the client signed on directly with us for a year and mandated the agency learn the tool and manage it as part of their remit. As you would expect took full credit for the implementation and the resulting traffic and revenue increase.
Another big problem we encounter which I will go into more detail in a separate article is Checklist SEO. We stopped offering our single-use product since we had a lot of agencies using it to create HREFLang site maps for clients just to check the box that they created HREFLang XML site maps for their clients with no intention of updating them. We asked them about ongoing management and they responded: “we just need to do one to check it off the list” and we don’t have the budget to pay for ongoing updates. If the site is not updating often then there is no need but in all cases, these were commerce sites that have products updating frequently. We had other cases where the agency told their client it was a software error as to why they were not updating. When the client contacted us for the support we had to tell them the agency signed them up for single use and there were no updates.
We recommend to our consulting clients that if they can do it internally go ahead and do it they become part of the site and it updated dynamically and all is good. But until they are 100% confident it is working correctly and will continue to work they should continue to use a solution that does actually work. In the blog there are a number of examples of where it can go wrong and we are working on a checklist of things to validate before you go live to ensure that it is correct. The most sucessful implementations are those were we set it up using HREFLang Builder and get the pages indexed and mapped and once the final QA is done for the internal soltion it swaps over. We can even create a seprate account to import the data from the current build to ensure it is correct.