Why does Google display inconsistent sitelinks when your internal anchors are clean?

How does Google select the text for sitelinks displayed in the SERPs?

Google relies on two fundamental elements to generate sitelinks: the hierarchical structure of the site and the internal anchor texts it detects during crawling. Contrary to popular belief, you cannot force Google to display a specific sitelink—the algorithm decides on its own based on what it deems relevant for the user.

The descriptive text accompanying each sitelink is not randomly chosen. Google extracts this text directly from the anchors it recognizes in your internal linking, sometimes combining multiple signals (title tags, headings close to the anchor, semantic context). If the displayed text is coherent, it means Google has correctly interpreted your anchors. If it is incoherent or unreadable, something is wrong upstream.

Why would Google display strange text in my sitelinks?

Two main scenarios emerge. First case: Google cannot read your anchors correctly. This often happens with client-side generated links in JavaScript, especially if deferred rendering is problematic or if Googlebot does not execute the JS as expected. Faulty character encoding (misconfigured UTF-8, broken HTML entities) also produces this type of gibberish.

Second case: your pagination is poorly structured and Google does not know which page to choose from a numbered series. As a result, the algorithm randomly picks a page, retrieves an anchor text that corresponds to nothing logical, and displays it in the sitelinks. This problem often affects e-commerce sites with filters or poorly tagged paginated listings.

Should I always report a sitelink problem to Google?

No. Before reporting a bug through official channels, thoroughly audit your own linking. Nine times out of ten, the problem comes from your side: dynamically generated anchors without SSR, links hidden in non-crawlable dropdowns, internal redirects in chain that confuse the signals.

If after a rigorous audit—manual inspection of the source code, testing with an independent crawler (Screaming Frog, Oncrawl), checking the encoding—you find that your anchors are perfectly clean and readable, then yes, you can report the issue to Google. But be specific: the relevant URL, a screenshot of the problem, relevant source code. Vague reports are ignored.

• Site structure and internal anchors: the two pillars of sitelink generation by Google
• Incoherent text = technical problem: unrendered JavaScript, faulty encoding, poorly structured pagination
• Internal audit before reporting: nine times out of ten, the problem comes from your implementation
• Dynamic anchors and crawl: client-side generated links must be tested with a crawler to check their actual accessibility
• No direct control: impossible to force Google to display a specific sitelink, the algorithm decides on its own

Does this explanation reflect the reality observed on the ground?

Yes, and it's quite rare for Google to be so explicit about an internal mechanism. In hundreds of audits, the pattern holds: when sitelinks display strange text, there is almost always a problem with internal anchors. Either they are generated in JS without a proper HTML fallback, or the encoding is faulty (hello to "é" transformed into "é"), or it is a multilingual site with faulty hreflang that mixes languages in the anchors.

The point about pagination is particularly accurate. Sites that use ?page=2, ?page=3 without rel="next"/rel="prev" tags (which are deprecated but still useful internally for structuring) or without coherent canonicals end up with sitelinks pointing to "Page 7" with a generic anchor text. Google does not know which page is the reference, so it picks at random.

What nuances should be added to this statement?

Mueller remains deliberately vague about the exact criteria for selecting sitelinks. He says "site structure and internal anchors" but does not specify the weight of each signal or how Google prioritizes multiple competing anchors pointing to the same URL. [To be verified] in controlled tests: does the first anchor in the DOM take precedence? Does the most frequent anchor prevail? Or is it a finer semantic mix?

Another point: he mentions "reporting the case" if everything seems clean on the site side, but there is no guarantee of quick processing. Reports via Search Console or Twitter can take weeks or even months without a response. In practice, it is better to fix your implementation than to wait for a hypothetical fix from Google.

In what cases does this rule not completely apply?

Sites with very little structured internal linking—typically one-page sites or isolated landing pages—simply will not have sitelinks due to a lack of exploitable material. Google may also choose not to display sitelinks if the query is too competitive or if historical CTR shows that users do not click on them.

Finally, certain rich formats (FAQ schema, Breadcrumb schema) can indirectly influence the selection of sitelinks, even though this is not the primary mechanism. Field observation: sites with solid schema markup tend to have more coherent sitelinks, probably because Google cross-references multiple signals to validate relevance. [To be verified] with schema A/B tests.

What should be prioritized in your audit if your sitelinks display odd text?

First step: check the server-side rendering of your links. Disable JavaScript in your browser (DevTools > Settings > Debugger > Disable JavaScript) and reload the page. If your navigation links disappear or display empty anchors, it means Googlebot may not see them correctly, even with deferred rendering. Use a crawler like Screaming Frog in "Render JavaScript" mode to compare what Google sees actually.

Next, inspect the character encoding. Open the source code (Ctrl+U) and look for malformed HTML entities or special characters that display strangely. Ensure that your <meta charset="UTF-8"> tag is present and that your server sends the correct Content-Type: text/html; charset=UTF-8 header. Poor encoding transforms your clean anchors into gibberish that Google will faithfully copy into the sitelinks.

How to fix a pagination problem that generates random sitelinks?

If Google picks randomly numbered pages for your sitelinks, it means your pagination lacks clear structure. First action: define a canonical page for each paginated series. Generally, page 1 should be the reference, with a rel="canonical" self-referential. Pages 2, 3, etc. can point to page 1 if the content is identical or be self-canonical if each page has unique content.

Second action: improve the internal linking to the main page. If your navigation displays "Page 1", "Page 2", "Page 3" with generic anchor texts, Google does not know which to prioritize. Replace them with descriptive anchors ("Full Catalogue", "New Arrivals") and ensure that page 1 receives more internal links than the others. This enhances the hierarchy signal for Google.

What common mistakes should be absolutely avoided?

Do not multiply different anchors pointing to the same URL. If ten pages of your site link to /contact with ten different anchor texts ("Contact Us", "Write to Us", "Support", etc.), Google will have to decide—and it may not choose the anchor you prefer. Standardize your internal anchors for strategic URLs.

Another classic mistake: generating links with non-crawlable dynamic attributes. Links onClick="navigateTo('/page')" without an <a href="/page"> tag in the DOM will never be seen by Googlebot. The same goes for links hidden in dropdown menus that require a hover or a click to appear in the DOM—Googlebot does not simulate these complex interactions.

• Test rendering without JavaScript to ensure that anchors are present in the raw HTML
• Validate UTF-8 encoding in the source code and HTTP headers
• Crawl the site with an independent tool to compare with what Google actually sees
• Define clear canonicals for paginated series and strengthen linking to the main page
• Standardize internal anchor texts for strategic URLs
• Ensure all links are in the initial DOM, not dynamically generated on click or hover