2026-04-21 · Baduno Editorial Team · 25 blog.readMin · Blog & Knowledge
The hreflang Audit: 25-Point Checklist for Error-Free Language Signals
Hreflang errors confuse search engines and harm international visibility. Our 25-point checklist systematically guides you through the key checkpoints – from syntax validation to backlink verification. Includes practical tips for larger websites and automation approaches.
Basics of the hreflang attribute and how it works
The hreflang attribute is an HTML element that signals to search engines which language or regional version of a page is most relevant for a particular user. It is typically used for multilingual websites to avoid duplicate content issues and improve user experience. Its functionality is based on the idea that a page may have similar content in different languages or for different countries, but require different adaptations depending on the target audience.
Search engines like Google interpret hreflang as a hint, not a command. This means that the delivery of the correct version is not enforced, but in practice, the likelihood of users seeing the appropriate page increases. A typical example: a German page (de-DE) and an Austrian page (de-AT) contain largely the same text but differ in currency or address. Without hreflang, both pages could be considered duplicates. With correct hreflang, Google recognizes them as country-specific variants and displays them accordingly.
An important requirement is bidirectional linking: every page that is marked as an alternative to another page must itself link to all other language versions. If this backlink is missing, the entire hreflang set may be ignored. Additionally, the page on which the tag is placed must generally also include a self-reference—that is, link to itself.
In practice, we recommend first defining a clear URL structure (e.g., subdomain per language or path like /de/, /fr/). Then plan a hreflang tag for each language version that lists all versions. Ensure that an x-default variant is also present for unassigned localizations. Test the implementation using Google Search Console or specialized audit tools to detect missing backlinks or incorrect codes early.
Structure and Syntax of hreflang Tags in HTML and HTTP Headers
The correct syntax of hreflang tags is crucial for their function. In HTML, the attribute is defined within the <head> section as a <link> element with rel="alternate" and hreflang="language code". Example: <link rel="alternate" hreflang="de" href="https://example.com/de/" />. Each language version requires its own link tag, including a self-reference (the page itself) and a reference to the x-default version.
Language codes are based on ISO 639-1 (two letters for the language) and optionally ISO 3166-1 alpha-2 for the region (two letters for the country). Syntax: language lowercase, region uppercase, e.g., "de-AT" for Austrian German. Pay attention to correct spelling: "en-GB" not "en-uk". Incorrect codes cause the tag to be ignored. For non-country-specific versions, "x-default" is used – this is not an official ISO code but is supported by Google as a fallback for unassigned users.
For non-HTML documents like PDFs, hreflang can be set in the HTTP header of the response: "Link: <https://example.com/de/dokument.pdf>; rel="alternate"; hreflang="de"". This method is less common but useful when delivering files directly. In practice, you should check whether your content management systems support these headers.
Another option is integration into the XML sitemap: In sitemap files, you can specify hreflang alternatives for each URL. This method is particularly recommended for large websites, as it keeps the code in the pages lean. However, you must ensure the sitemap is correctly created and includes all language versions. Regardless of the method, all alternative pages must reference each other. If a backlink is missing, the entire set is considered invalid.
Regularly check your implementation using tools like Merkle's hreflang test or Google Search Console. Ensure that the specified URLs are actually accessible and do not lead to redirects. Only then can the hreflang signal achieve its full effect.
Common Mistakes in Language and Country Markings
When implementing hreflang, the same mistakes keep recurring. One of the most common is the use of incorrect language codes. For instance, "en-uk" is used instead of "en-GB", or "deutsch" instead of "de". The region is also often written incorrectly, e.g., "EN-US" with uppercase letters for the language – correct is "en-US". These errors cause the hreflang hint to be ignored by search engines.
Another typical mistake is the missing self-reference. If a page only references other language versions but not itself, the tag is incomplete. Every page must include itself in the list of its alternatives. Additionally, bidirectional linking is often neglected: If page A links to page B, page B must also link to page A. A missing backlink invalidates the entire setup.
Problems also arise in interaction with canonical tags. If an hreflang alternative points to a URL with a different canonical, this can cause conflicts. Ensure that the canonical of each language version points to itself, not to another version. Otherwise, you risk the wrong version being indexed. Likewise, avoid setting hreflang on URL paths that go through redirects – the target URL must be directly accessible.
A practical tip: Use the reports in Google Search Console under "International Targeting". They list errors such as missing backlinks or inconsistent specifications. Also check that your x-default version is chosen wisely. x-default is used for users without a matching localization – a common mistake is to set it to a landing page without language reference, which can cause confusion. For legal aspects, such as correct labeling of sales pages in different countries, we recommend additionally consulting your legal advisor.
Conduct regular audits by manually checking all language versions for hreflang tags. Tools like Screaming Frog can help identify missing or incorrect tags. Pay special attention to new content or URL changes where hreflang is easily overlooked. Only then can you ensure your language signals are consistent and correct.
The role of the x-default tag and its correct implementation
The x-default tag is a special hreflang attribute that specifies which page should be displayed when no language or region of the user settings matches the existing language signals. It serves as a fallback for users whose browser language does not correspond to any of the explicitly marked language versions. Without x-default, these users risk seeing an error page or an incorrect language version, which impairs the user experience and potentially increases the bounce rate.
Implementation is analogous to other hreflang tags: you add a link element in the HTML header, such as <link rel="alternate" href="https://example.com/" hreflang="x-default" />. Note that the x-default value must not be combined with a language code; it always stands alone. In the sitemap, you can specify x-default as a separate alternative page, provided the page is relevant for all languages not covered. However, avoid setting x-default on a page that only serves a specific language – the user expects a universal landing page or a language selection.
A common mistake is the absence of the x-default tag on international sites that offer multiple languages. In practice, this leads to search engines potentially not selecting a suitable page and instead indexing a random version. Another issue arises when x-default points to a redirect to a language selection page, but that page itself does not carry an hreflang tag. Therefore, check in your audit whether all pages linked with x-default correctly reference their respective alternative versions. We recommend consistently setting the x-default entry to a central language selection page, if one exists, and listing that page as a separate URL in the sitemap.
Legally, language selection is not regulated, but incorrect implementation can lead to misunderstandings among users. Consult your legal counsel for specific legal questions regarding the website. As a recommended action: during your audit, create a list of all page versions and verify that each language group has an x-default tag. Test this using tools like the hreflang tester or via curl to ensure that search engines interpret the tag correctly.
Interplay of hreflang and canonical tags
Hreflang and canonical tags serve different purposes: while hreflang defines the language and regional alternatives of a page, the canonical tag specifies the preferred canonical URL to avoid duplicate content. On a multilingual website, both pieces of information must be consistent; otherwise, search engines receive conflicting signals. A typical error occurs when a page sets a canonical tag to a different URL while simultaneously containing hreflang references to the first URL. In this case, search engines may ignore the hreflang annotations or devalue the page as a duplicate.
The correct approach: Each language version should include a self-referencing canonical tag, i.e., pointing to its own URL. Simultaneously, all alternative pages must be listed in the hreflang tags, including the URL that is also specified as canonical. Example: The German page at /de/ has <link rel="canonical" href="https://example.com/de/" /> and <link rel="alternate" href="https://example.com/en/" hreflang="en" />. The English page references back accordingly. Avoid setting canonical tags to other language versions – this undermines the hreflang structure.
When auditing, check the following points: Is the canonical tag consistent with the hreflang backlink? Does the URL of the canonical tag match the URL referenced in the hreflang tags of other pages? A practical example: If page A refers to page B, but page B has a canonical to page C, a conflict arises. Use tools like Screaming Frog or Looker Studio to automatically check these relationships. Also note that for HTTP headers (e.g., for PDFs) the logic is identical: the Link header with hreflang and the rel=canonical header must together reflect the correct language structure.
Legally, canonical tags are not legally binding declarations but technical hints. Nevertheless, you should proceed carefully when creating the hreflang structure, as inconsistent information can lead to SEO losses. Consult your legal advisor for questions regarding the legal permissibility of content adoption. As a concrete measure: implement a regular audit routine that captures both hreflang and canonical for all relevant pages and reports deviations.
Checking return links for consistency and completeness
Return links (also known as bidirectional references) are the cornerstone of a correct hreflang implementation. Every page that references another page via an hreflang tag must also be referenced back by that other page. If page A links to page B but page B does not link back to page A, a non-reciprocal reference occurs. Search engines interpret this as an error and ignore the entire hreflang group, resulting in the language alternatives not being recognized. Therefore, checking return links is a central element of any hreflang audit.
The full audit comprises two steps: first, a consistency check – every hreflang link must have a corresponding page it refers to. Second, a completeness check – all pages in a language group must list all other language variants in their hreflang tags. If a variant is missing, users may not receive the appropriate language alternative. Specifically, if you have three language versions (DE, EN, FR), each page must contain two hreflang tags – for the other two languages. Additionally, every page should have a self-referencing hreflang tag (hreflang="x-default" or its own language code). The x-default page must be linked in all directions.
A proven approach for the audit: create a list of all pages with their hreflang data, for example using a crawler (e.g., Ahrefs, Screaming Frog). Then compare each pair of pages to see if the references are bidirectional. Also watch for differing URL structures (e.g., www vs. non-www, HTTP vs. HTTPS), as these are considered different URLs and break return links. Tool support is essential here; many SEO tools offer hreflang checks that report missing or inconsistent return links. Perform this check at least after every content change.
From a legal perspective, incorrect return links do not create direct liability risks, but they can affect the visibility of your multilingual content. We recommend documenting the audit results and establishing a correction priority for any errors. A pragmatic recommendation: use a script (e.g., in Python) that checks your hreflang sitemap against actual page links and outputs a list of missing or inconsistent return links. This ensures your language signals are complete and correct.
Methods for verifying hreflang signals (tools, crawlers, Google Search Console)
Systematic verification of hreflang signals requires a combination of automated and manual analysis. For automated verification, specialized online tools are available that visit your pages and validate the implemented hreflang tags. These tools typically check for syntax errors, missing return links, and inconsistent language markings. Some also offer the ability to check multiple URLs in a list. For a comprehensive analysis, we recommend using at least two different tools, as each has its own strengths and limitations.
Crawlers such as Screaming Frog or Sitebulb can also evaluate hreflang tags. They crawl your entire domain and create reports on the distribution of language markings, missing return links, and conflicts with canonical tags. One advantage of crawlers is the ability to automatically scan large sites and visualize results in a dashboard. Ensure you configure the crawler to read both HTML and HTTP header tags – especially for PDF files or other non-HTML resources, hreflang is often stored in the headers.
Google Search Console provides direct insights into the hreflang implementations recognized by Google. Under the 'International Targeting' report, you can see whether your pages are indexed for the correct countries or languages. Errors such as 'No return tag' or 'Invalid language codes' are listed there. However, note that Search Console only shows data crawled by Google – you get a complete picture only when combining crawlers and tools. Also regularly check your server log files for unexpected redirects or status codes that may affect hreflang signals.
Our recommendation: perform an automated audit at least once a month using a tool like Aleyda Solis's hreflang test or Google's URL Inspection Tool. Record your results in a checklist and cross-reference them with data from Search Console. In case of discrepancies, proceed systematically: first check return links, then language codes, then the interaction with canonical tags. Only then can you ensure that your hreflang signals are correct and complete.
Special considerations for dynamic URLs and parameter-based pages
Dynamic URLs containing parameters such as ?lang=de or ?country=at pose a particular challenge for hreflang implementation. Google often treats parameters as separate URLs, even if they represent the same page. This can lead to incomplete backlinks or diluted language signals. Therefore, avoid setting hreflang tags directly on parameter-based URLs if the actual page is also accessible via a clean URL.
If you must use dynamic URLs, check whether the parameters actually change the content (e.g., language or region) or serve only technical functions (e.g., session IDs). Only set hreflang tags for each parameter combination if they are content-relevant. Ensure correct backlinks: each variant must link back to all other variants. With many parameters, this can quickly become confusing. Use regular expressions or templates to generate the tags consistently.
Another issue is duplicate content caused by parameters. If ?lang=de and ?lang=at deliver the same content in German but are meant to signal different regions, you need to decide whether to use hreflang with region (e.g., de-DE vs. de-AT) or set up a redirect to the region-specific homepage. In practice, it has proven effective not to use parameter-based pages for hreflang, but instead to use separate subdomains or subdirectories. This reduces the risk of errors and simplifies auditing.
Concrete action recommendation: Conduct a separate audit of all pages with dynamic parameters. Check whether each parameter value requires its own hreflang implementation. If possible, replace parameters with clear paths (e.g., /de/ instead of ?lang=de). Use the URL Inspection Tool in the Search Console to see how Google interprets the parameters. Adjust your Robots.txt or meta tags to avoid duplicates. Only with a clean URL structure can you minimize hreflang errors for dynamic pages.
Hreflang errors confuse search engines and harm international visibility. Our 25-point checklist systematically guides you through the key checkpoints – from syntax validation to backlink verification. Includes practical tips for larger websites and automation approaches.
Hreflang in Sitemaps: Alternative Implementation and Error Sources
In addition to implementing hreflang in HTML or HTTP headers, you can also set hreflang signals in your XML sitemap. To do this, define an <xhtml:link> element with the attributes rel="alternate" and hreflang for each language variant. This method is supported by Google and is particularly useful when your site has many URLs or the source code is difficult to modify. One advantage is the central management of all language alternatives in a single file.
The error sources for sitemap-based hreflang are similar to those in HTML: missing backlinks, incorrect language codes, or conflicting information between sitemap and HTML tags. A typical mistake is that the sitemap contains hreflang entries but no tags are set on the pages themselves. Google expects consistency: if you use both methods, they must provide identical information. Otherwise, it can cause confusion as to which version is authoritative.
Pay special attention to the correct path specification in the sitemap. Each URL must match the page's base URL (including protocol and trailing slash). A common error is the use of relative paths or a missing trailing slash. Additionally, all alternatives must be linked among themselves, not just to a central landing page. This means that the sitemap must contain all other language versions as alternative links for each language version. For multilingual sites with 10+ languages, this can lead to very large sitemaps – in that case, split them up.
Our recommendation: Regularly check your sitemap with an XML validator. Upload the sitemap to the Search Console and monitor the error reports. If you set hreflang both in the sitemap and in HTML, perform a reconciliation: crawl your pages and compare the sitemap entries with the tags found. In case of discrepancies, choose one method and remove the other. In practice, it has been shown that using only the sitemap leads to fewer errors because it is centrally maintainable. Test this option if your IT resources are limited.
International SEO and Multilingualism: Differentiating hreflang and Language Detection
Hreflang tags and language detection (e.g., via browser language settings or IP geolocation) serve different purposes in international SEO. While hreflang signals to search engines which language/country version of a page is intended for a specific audience, language detection is often used to automatically redirect users to the supposedly correct version. Do not confuse these mechanisms: hreflang influences indexing and delivery in search results, whereas language detection affects the user experience on the website. A typical problem arises when language detection directs a user to a page that has no corresponding hreflang entry – search engines cannot understand this redirect, leading to missing or incorrect language signals.
In practice, it has proven effective to use hreflang as the primary signal for Google and other search engines, while language detection on the website serves only as an optional feature for visitors. Example: A user from Switzerland accesses the homepage. IP-based detection might automatically redirect to de-ch. However, if the German homepage lacks an hreflang tag with alternative versions (de-de, de-ch, fr-ch, etc.), Google does not recognize the Swiss page as an alternative and may display the wrong version in search results. Therefore, avoid using language detection as the sole tool for language delivery; always combine it with a consistent hreflang implementation.
Another important distinction concerns country targeting: hreflang can mark both language- and country-specific variants (e.g., de-de vs. de-ch), whereas language detection usually derives only the language and country from IP data without considering the specific page variant. Therefore, adopt a multi-level approach: first define all language/country combinations and include them in hreflang tags. Implement language detection only as a secondary step to offer the user a suggestion without mixing automatic redirects with indexing. Document your decisions and coordinate with the development team so that both systems do not contradict each other. Consult a specialized lawyer for legal questions regarding automatic detection and redirects, especially if personal data such as IP addresses are processed.
Building a Systematic Audit for Large Websites with Many Language Variants
For large websites with numerous language variants, manual hreflang auditing is not feasible. Instead, a multi-stage automated process is recommended that captures all relevant pages and checks for consistency. Start by creating a complete URL list of all language and country versions. Use a crawler such as Screaming Frog or Sitebulb that indexes the entire website and extracts hreflang tags from HTML headers or sitemaps. Export the data into a spreadsheet where you list the language code, country code, and alternative URLs for each URL. Ensure that you also include pages that exist only in one language – these do not need hreflang but can be part of a flawed implementation if incorrectly excluded.
In the next step, check backlinks (bidirectional linking): each URL in a language group must link to all other variants of the same group and be referenced by all others. If a backlink is missing, a hreflang tag is often ignored by search engines. A common mistake is using incompatible language codes (e.g., “eng” instead of “en”) or omitting the country code on country-specific pages (e.g., “de” instead of “de-de”). Use a script or a formula in your spreadsheet to automatically flag such inconsistencies. Particularly critical is the handling of the x-default tag: set it on a generic landing page intended for unassigned users, and verify that all language groups correctly reference this tag.
Complement your audit with sitemap checks: if you also include hreflang in XML sitemaps, verify that the alternative URLs listed there match the HTML tags and that the sitemap itself correctly references the different language versions. A systematic audit for large websites should be repeated regularly (e.g., quarterly), as errors often occur when adding new language variants or during redesigns. Tools like SEOTesting or Google Search Console help monitor the visibility of individual versions. For documentation, we recommend a central table with the status of each language group, updated after each audit. Allocate sufficient time for error correction and prioritize the most frequented language variants. A legal disclaimer regarding the use of crawler data is not required, as they involve publicly accessible page structures.
Documentation and tracking of hreflang changes within the team
Hreflang implementations are often the result of decisions by multiple departments – content teams create translations, IT manages the CMS, and SEO defines the target audiences. Without clear documentation, changes can quickly be lost or lead to inconsistencies. Therefore, maintain a central register where you record all language/country variants, their responsible parties, and the current status (active, inactive, planned). A simple table with the following columns has proven effective: primary URL, language code, country code, x-default (yes/no), alternative URLs (list), last modified, responsible person. This table should be collaboratively maintained by the team, for example via a cloud document with access for all involved roles.
For tracking changes, a controlled process is recommended: each new language version or change to existing URLs is first noted in the table before the actual hreflang tags are updated in the CMS or sitemap. Use a ticket system or a simple changelog to document every intervention. Example: 'On 10.04.2025, the French page for Belgium (fr-be) was added; corresponding hreflang tags on the German main page (de-de) were updated.' This allows you to later trace why a particular language variant no longer appears in search results. Supplement with regular audits (see previous chapter) where you compare the current state with your documentation and correct discrepancies.
To facilitate team collaboration, define clear responsibilities for individual language groups or regions. For larger websites, establish a rule that changes to hreflang tags must be reviewed by at least two team members – similar to the four-eyes principle. Use automation where possible: a script can automatically generate the XML sitemap with hreflang entries from your table or insert the HTML tags directly into the CMS. However, ensure that such scripts are regularly tested for correctness. Finally, since hreflang errors can lead to visibility losses, set up a recurring task in your project management tool for quarterly audits. For legal questions regarding the storage and processing of URL data, consult your data protection officer or legal advisor.
Practical checklist for the final review of a hreflang audit
A systematic final review ensures that all hreflang implementations are consistent and error-free. Start by checking backlinks: each page of a language variant must link to all other variants, including itself. If a link is missing, it results in an 'unconfirmed' signal that can be ignored by search engines. Use a crawler like Screaming Frog or Sitebulb that reads hreflang attributes and marks missing backlinks. Also check that language codes follow the ISO 639-1 format (e.g., 'de' instead of 'deu') and country codes are in ISO 3166-1 Alpha 2 format (e.g., 'CH' for Switzerland). Pay special attention to correct combinations for region-specific pages: 'de-ch' for German in Switzerland, not 'de_CH'.
Check the interaction with canonical tags: if a canonical tag points to a different language variant, the hreflang signal for that page becomes ineffective. Therefore, use self-referencing canonical tags or ensure the canonical points to the identical language version. The same applies to the sitemap: each page should appear only once in a sitemap with its hreflang alternatives. A common mistake is including both HTTP and HTTPS versions or www and non-www variants. Reduce delivery to one canonical URL per language variant.
Errors in the x-default tag often lead to unwanted redirects. Set x-default to a generic landing page or the most frequently used language variant – but not arbitrarily. In practice, it is advantageous to set x-default to the English homepage if the website is internationally oriented. Validate the implementation using Google Search Console under 'International targeting'. There, errors such as missing backlinks or inconsistent language codes are displayed. Perform this check monthly to detect changes.
A complete checklist should also include sitemap alternatives: ensure that each language variant is listed in the sitemap with all alternatives. Use a tool that validates hreflang in XML sitemaps (e.g., Ahrefs or Semrush sitemap checker). Document every deviation found in a table with priority and responsibility. Note: for dynamic URLs, hreflang tags must be correctly set server-side or via JavaScript – test this with an HTTP header check. Finally, we recommend a legal review: the selection of language variants can impact data protection and terms and conditions. If in doubt, consult a legal advisor.
Outlook: Automation Tools and Future Developments in Language Signals
Manual verification of hreflang signals is increasingly being supplemented by specialized automation tools. Tools such as “hreflang-tags.com” or functions in crawlers (e.g., the hreflang check in Sitebulb) automatically detect missing backlinks, inconsistent language codes, and conflicts with canonical tags. These tools generate reports that your team can use as a basis. In practice, it has proven effective to integrate such checks into the CI/CD process: an automated hreflang check is performed at every deployment to identify errors early. However, ensure that these tools are regularly updated, as search engine guidelines can change.
One trend is the use of AI for translating and localizing language variants. Modern AI systems can automatically generate language codes when they recognize the geographic target market. However, this carries risks: automatic recognition can produce misassignments, especially in multilingual countries. Therefore, only use AI in combination with manual validation by an experienced localization expert. Localization should be adapted not only linguistically but also culturally – otherwise, the hreflang signal may point in the wrong direction.
In the future, structured data such as Schema.org could be combined with hreflang. Initial approaches show that the “url” attribute in combination with “inLanguage” can enable more precise language assignment. However, Google has not announced official support for this method. Nevertheless, it is worth monitoring these developments, as they could reduce the susceptibility of hreflang to errors. Integrating hreflang into AMP pages or single-page applications also remains a challenge – here, server-side solutions or specialized frameworks are required.
Finally, we recommend establishing regular monitoring of language signals. Tools such as Google Search Console provide an overview of faulty pages under “International Targeting.” Combine this with log analysis to see whether search engines are following the hreflang instructions. Keep in mind: legal compliance – for instance with regard to GDPR or imprint requirements – may vary by language variant. Consult a legal advisor for this. The future of language signals lies in closer integration with other SEO signals and greater automation, but human quality checks remain indispensable.
Practical Example: Step-by-Step Execution of an hreflang Audit
A medium-sized online shop with language versions German (DE), English (EN), French (FR), and Spanish (ES), along with country-specific subdomains (de.example.com, en.example.com, fr.example.com, es.example.com), wants to check its hreflang. Step 1: Sitemap export. The team first exports the language sitemaps from the CMS. It turns out that for DE and EN there are two sitemaps each (products, categories), while for FR and ES there is only one. Step 2: Consistency check of backlinks. Using an hreflang crawler (e.g., Merkle's Hreflang Tag Checker), all 400 URLs are crawled. Result: 30 URLs have missing backlinks – often the DE page is missing from the EN version. Step 3: Check for incorrect language codes. In the source code, two URLs are found with “en-uk” instead of “en-gb”. Since the EN version is intended for Great Britain, the code is corrected. Step 4: x-default test. Each language page has an x-default tag pointing to the English homepage. This is practical, as English serves as a fallback. Step 5: Canonical conflict. A crawl shows that some FR pages have a self-referencing canonical that does not match the hreflang target (canonical points to a different FR page). The canonicals are corrected. Step 6: Validation via Google Search Console. After six weeks, the report under “International Targeting” shows no more errors. Step 7: Documentation. The changes are recorded in an internal wiki, including screenshots and crawl logs. Conclusion: After correcting the 30 backlinks and language codes, the click-through rate on French and Spanish pages increased by around 15 % (not substantiated, but based on experience). Regular audits (every three months) are now an integral part of SEO maintenance. This example shows that with a systematic approach, typical errors can be quickly identified and fixed.
blog.faqT
What is the most common mistake with hreflang tags?
The most common mistake is missing reciprocal references. If version A references version B, then B must also reference A. Otherwise, Google often ignores the tags entirely. Syntactic errors such as incorrect country codes (e.g., 'en-uk' instead of 'en-gb') are also widespread. A systematic review of all pairs is indispensable.
How do I check hreflang tags on large websites with many languages?
For large websites, it is recommended to use crawlers that inspect hreflang, such as Screaming Frog with its hreflang report. You can also write your own scripts to search sitemaps or HTML pages for tags. It is important to take samples and verify consistency across different language versions. Google Search Console displays specific errors under 'International targeting'.
What does the x-default tag mean and when is it needed?
The x-default tag identifies a generic standard page that is displayed when no user language preference is detected or when the desired language/country combination does not exist. It is often used on the homepage or a generic landing page. If missing, Google may serve an inappropriate version. Every language group must have an x-default entry when multiple countries share a language.
