Fixing Hreflang: Lessons From a TR/EN Site Migration
On one site rebuild we were brought in to fix, the client had a working Turkish site and an English version added later as a subfolder, /en/. The constraint was simple: no budget for a separate domain or subdomain, and no time to rebuild the URL structure. Everything had to work inside the existing folder setup, with hreflang tags doing all the heavy lifting between languages.
The site had been live for over a year before anyone noticed a problem. Turkish users searching in Google were occasionally landing on the English homepage. English-speaking visitors, mostly from organic search tied to international keywords, were sometimes shown Turkish category pages instead. Nobody had touched hreflang deliberately; it had been added once during the initial build and never revisited since.
What the audit actually found
We started by pulling every URL with its hreflang annotations through a crawler and comparing that against what Google Search Console reported under the International Targeting data, now folded into the indexing reports, though the underlying signals still matter the same way. The mismatch showed up almost immediately: about forty category pages had hreflang pointing to an EN equivalent that had been deleted three months earlier during a content cleanup. Those tags were still firing, just pointing at 404s.
Beyond the dead links, we found a more common issue: hreflang tags that pointed to themselves correctly but carried no return tag on the paired page. Hreflang only works as a confirmed pair. If the Turkish page says this content also exists in English at this URL, the English page needs to say the same thing back, pointing to the Turkish version. Google ignores one-directional tags, and this site had dozens of them, mostly on pages added after the initial launch, where whoever updated the template forgot to update both sides.
There was also a subtler problem: several pages used the wrong language code format in their hreflang values. Some tags used en instead of en-US or en-GB when the content was explicitly aimed at a specific market, and a few used tr-TR when tr alone would have matched more broadly. Google tolerates these inconsistencies fairly well, but x-default was missing across the entire site, which meant visitors whose browser language matched neither tr nor en had no clear fallback page assigned to them.
Why we rebuilt the tags from the sitemap instead of the templates
The original implementation had hreflang baked into page templates, generated per content type. That approach breaks the moment someone deletes a page, renames a slug, or adds a new language variant without touching every related template. We moved hreflang generation into the XML sitemap instead, since sitemaps are already structured data that regenerates automatically whenever content changes.
This meant writing a script that pulled the list of all TR/EN page pairs from the CMS, verified both sides actually existed and returned a 200 status, and only then wrote the hreflang block into the sitemap. Pages without a confirmed pair on both sides got skipped from hreflang entirely rather than pointing at something broken. It's a conservative approach, and deliberately so: a missing hreflang annotation on an orphan page costs far less than a broken one that erodes trust in every other signal on the domain.
We also added x-default pointing to the Turkish version, since the client's primary market was domestic and the English site existed mainly to serve international B2B inquiries rather than compete for broad English-language search volume. That call depends entirely on where the business actually gets its traffic and revenue. A site built primarily for international buyers would reasonably default the other way.
What improved, and what the fix actually cost in time
Within a few weeks of the corrected sitemap going live and being resubmitted through Search Console, mismatched impressions dropped noticeably in the International Targeting report. The ratio of Turkish users landing on English pages, and the reverse, fell close to zero in the following month's data. That part worked roughly as expected once the tag pairs were actually correct and pointing at live URLs.
What we underestimated was the canonical tag conflict. Several English pages carried a canonical tag pointing back to the Turkish version, left over from an early phase when the EN pages were thin translations and someone had set canonicals to avoid duplicate content penalties that, in hindsight, were never really a risk given the content was in a different language. Hreflang and canonical tags that disagree send a contradictory signal: one says this is a separate, valid version for this audience, the other says ignore this page, the real one is elsewhere. Google generally trusts the canonical over the hreflang in that situation, which meant some EN pages had been effectively invisible for months despite having correct hreflang pointing to them.
Fixing the canonical mismatch took about a week of manual review, page by page, because the CMS did not expose canonical tags in bulk and we had no reliable way to script the correction without risking unrelated pages. That week of manual work was the real cost of the original oversight, not the hreflang rebuild itself, which took closer to three days once the sitemap script was working.
What we would set up differently from day one
If we were starting this project again, we would treat hreflang and canonical tags as one combined checklist item from the first content model decision, not two separate settings configured by different people at different times. On a project with both a Turkish and English site, whoever owns the CMS templates needs to see both tags on the same screen before publishing, not buried in separate SEO plugin tabs.
We would also set up an automated check, something as simple as a scheduled crawl comparing hreflang pairs against sitemap entries weekly, rather than relying on a manual audit triggered by someone noticing odd traffic patterns in analytics. That kind of ongoing monitoring is the sort of work we build into our services for clients running multilingual sites, since hreflang problems tend to stay invisible until they surface as a traffic anomaly nobody can immediately explain.
For businesses weighing whether a multilingual structure is worth the added technical overhead at all, the decision usually comes down to where actual demand exists. A manufacturing supplier based in Kocaeli selling to both domestic buyers and export clients in Europe has a real case for maintaining both language versions properly. A small local business with no international customer base is often better served keeping a single, well-maintained Turkish site rather than running a thin, rarely updated English mirror that creates exactly this kind of tag management risk.
We've seen comparable multilingual structures across different industries in our portfolio, and the sites that hold up over time are the ones where someone actually owns the language-pairing logic, not just the translation work. If you're planning a similar setup or trying to untangle an existing one, you can reach out through our get a quote page and we'll take a look at what's actually happening under the hood.
