BlogFindings
85 links carried no anchor text, and 34 were named only by aria-label
Counted with an HTML parser over five real pages this scanner captured and stored on 15 July 2026, the rendered DOM holds 1,951 links with an href and 85 of them carry no text between the tags. Google's link documentation names two fallbacks for an empty link, the title attribute and a nested image's alt text. Thirty four of the 85 carry neither, and 23 carry none of the three.
The measurement is narrow and the limits are stated below. Five pages is not a sample of the web, the captures are from one day, and nothing here says what any AI crawler does with the text it finds, because that is not observable from a stored page. What the count does establish is how often the visible text is simply absent, and what is left behind when it is. The same fixtures produced an earlier count of alt text on 466 captured images, and that number turns out to matter here for a reason that has nothing to do with accessibility.
In short
- Counted with an HTML parser over five real pages this scanner captured and stored on 15 July 2026, the rendered DOM holds 1,951 a elements carrying an href, and 85 of them hold no text between the opening and closing tags.
- Google's link best practices documentation, carrying Last updated 2025-12-10 UTC, names exactly two fallbacks for an empty link: the title attribute on the a element, and the alt attribute of a nested img. The page never mentions aria-label.
- Of those 85 textless links, 22 carry a title attribute and 27 carry a non-empty image alt. Thirty four carry only an aria-label or aria-labelledby, and 23 carry none of the three, of which 20 hold no image and no inline SVG either.
- Read on 22 August 2026, the crawler documentation pages published by OpenAI, Anthropic and Perplexity contain zero occurrences of the words anchor, link text or alt attribute. Google's is the only one of the four that states how a link's text is read.
- Lantad does not score anchor text. The structure sub-score is seven checks covering the title, the meta description, a single h1, the canonical, heading coverage, oversized blocks and llms.txt, and not one of them looks at a link.
Flow: a element with href to Text between the tags; Text between the tags (text present) to Anchor text Google can use; Text between the tags (empty) to title attribute; title attribute (title set) to Anchor text Google can use; title attribute (no title) to Nested img alt; Nested img alt (alt set) to Anchor text Google can use; Nested img alt (neither) to No documented anchor text.
What 1,951 links on five real pages actually carried
The five pages are the ones this scanner already stores as golden fixtures, captured and frozen on 15 July 2026: the Astro homepage, the Gymshark storefront, the MDN HTML reference, the Webflow homepage and the English Wikipedia article on web crawlers. They were chosen originally because they span four rendering strategies and one encyclopedia, and they have since become the sample every counting post here works from. Counted with an HTML parser over the stored rendered DOM, they hold 1,951 a elements that carry an href attribute.
The raw HTTP responses hold 1,957 of them. Running JavaScript therefore moved the link total by six across five pages, in both directions, which is consistent with the earlier finding that JavaScript added no new crawl paths on this same set. It is worth saying plainly because the intuition runs the other way: the common assumption is that a crawler which does not execute scripts sees a drastically smaller link graph, and on these five pages it does not. What it sees is very nearly the same set of links, with the same text problems in them.
Of the 1,951, 85 hold no text at all between the opening and closing tag. That is 4.4 percent, and it is not spread evenly. The Astro homepage has none: every one of its 133 links carries words. The MDN reference has five out of 452. Wikipedia has 15 out of 773. The two commercial marketing pages carry almost everything else, with 33 textless links out of 334 on Gymshark and 32 out of 259 on Webflow, which is 9.9 and 12.4 percent of their links respectively. The shape is familiar from the rest of this fixture set: the documentation and encyclopedia pages are built out of prose with links inside it, and the marketing pages are built out of components, where a link is frequently a tile, a logo, a carousel dot or an icon rather than a sentence.
None of this is a rendering failure and none of it is hidden text. Every one of these links is present in the DOM, has a resolvable href, and would be followed by anything that follows links. The question is narrower and, for retrieval, more interesting: when the crawler arrives at that link, does anything tell it where the link goes? That is a different question from whether the page can be fetched at all, which is the layer this site usually measures, and a different question again from prose parity between the raw and rendered documents. It sits underneath both, in the part of the document that is supposed to explain itself.
| Page, as captured on 15 July 2026 | Links with an href | Carrying no text | Share of that page |
|---|---|---|---|
| astro.build homepage | 133 | 0 | 0 percent |
| gymshark.com storefront | 334 | 33 | 9.9 percent |
| developer.mozilla.org HTML reference | 452 | 5 | 1.1 percent |
| webflow.com homepage | 259 | 32 | 12.4 percent |
| en.wikipedia.org Web crawler article | 773 | 15 | 1.9 percent |
| All five pages | 1,951 | 85 | 4.4 percent |
Google documents two anchor text fallbacks for an empty link, and aria-label is not one of them
Only one of the four crawler vendors this scanner probes publishes anything about how the text of a link is read, and it is the oldest one. Google's link best practices documentation, carrying Last updated 2025-12-10 UTC, states that Google can generally only crawl a link if it is an a element with an href attribute, defines anchor text as the visible text of a link, and then names two fallbacks for the case where that text is missing. First, as it puts it, Google can use the title attribute as anchor text if the a element is for some reason empty. Second, for images used as links, Google uses the alt attribute of the img element as anchor text.
That is the whole documented chain, and it is short enough to check a page against. The same page also names the anchor text it considers too generic, and the examples it gives are click here, read more, website and article. Across all 1,951 links on these five pages, four anchors match those examples exactly: one reading article, two reading read, and one reading link. So the failure Google's documentation spends most of its space warning about is close to absent here, and the failure it mentions in one sentence is the common one.
Applying the chain to the 85 textless links gives three groups, and they overlap, because a single link can carry more than one attribute. Twenty two carry a title attribute. Twenty seven carry a nested img with a non-empty alt, which is the point at which the earlier image count stops being an accessibility statistic and becomes a link statistic: an image's alt text is the anchor text of the link wrapping it, so a decorative empty alt on a linked logo removes the only documented name that link has. Three of the 85 wrap an image whose alt is empty or absent, which is exactly that case.
Fifty seven of the 85 carry an aria-label or an aria-labelledby. Thirty four carry only that, with no title and no image alt anywhere inside them. The word aria-label appears zero times on Google's link documentation. This is not a claim that the attribute is ignored, because that is not something a stored page can show and no vendor has published it either. It is a claim about what is documented, which is the only thing a site owner can act on. The distinction matters the same way it did when we found that an h1 inside a header element counted as no h1 at all in our own extractor, and when Google's deep links landed on sections where 55 of 245 headings had an id.
| What the textless link carries | Named by Google as anchor text | Links of the 85 |
|---|---|---|
| A title attribute on the a element | Yes, stated as a fallback | 22 |
| A nested img with non-empty alt | Yes, used as anchor text | 27 |
| An aria-label or aria-labelledby | No, never mentioned | 57 |
| Aria only, with no title and no alt | No documented text source | 34 |
| None of the three | No documented text source | 23 |
Thirty four links were named only for a screen reader, and 23 were not named at all
The aria-only group deserves care, because the obvious reading of it is wrong. These are not badly built links. MDN's reference for the aria-label attribute describes it as defining a string value that can be used to name an element, gives an icon button with no text as the standard example, and adds a note that because aria-label content is not displayed outside assistive technologies, important information should be made visible for all users. The attribute is specified in the WAI-ARIA recommendation and it is doing precisely the job it was designed for. A developer who puts an aria-label on an icon link has done the accessible thing, not the careless thing.
The finding is about what that leaves for a text pipeline, and it is a gap between two standards rather than a mistake inside either. An accessible name lives in the accessibility tree, which is a browser construct. Anchor text, as Google's page defines it, is the visible text of a link, with two attribute fallbacks neither of which is an ARIA attribute. On these five pages, 34 links sit in the space between: correctly named for one consumer, and carrying nothing that any published crawler documentation says it will read.
The 23 links carrying none of the three are a different case, and a simpler one. Twelve are on the Webflow homepage and 11 are on the Wikipedia article, and the pattern in the hrefs is the giveaway: most point at a fragment on the same page rather than at another document. Twenty of the 23 contain no image and no inline SVG either, so they are genuinely empty elements, which is the shape a CSS-styled control takes when the visual is a background image or a pseudo-element. A carousel dot is a link to nowhere in particular and it does not need a name. Wikipedia's citation backlinks are in the same family. Calling those a defect would be the kind of confident wrong grade this site refuses to emit, which is the same reasoning as withholding a grade rather than guessing it.
What is fair to say is that a page which routes a real destination through an unnamed control has spent a link and bought no signal with it. Distinguishing the two cases from the outside is hard, which is why this post reports the count rather than a verdict. It is also why the count is worth having: the number of links on a page that a text pipeline can describe is knowable, and on four of these five pages it is smaller than the number of links. Text that a browser assembles and a parser does not is a recurring theme here, and the closest previous case is text inside a shadow DOM and what the extractor does with it.
What an assistive technology gets
- aria-label supplies the accessible name
- The control is announced and operable
- MDN gives an icon link as the example case
- The developer did the specified thing
- 34 of the 85 textless links are in this state
What the documented anchor text chain finds
- No text between the opening and closing tags
- No title attribute to fall back to
- No nested image alt to fall back to
- aria-label appears nowhere in Google's link page
- The href resolves and the destination is unnamed
One word is not the problem, and the same two words on 26 destinations is
A count of textless links invites a second count that is easy to get wrong. Of the 1,866 links that do carry text, 920 carry exactly one word. It would be simple, and misleading, to file those as weak anchors. Nine hundred and twenty one-word anchors resolve to 629 distinct strings, and on an encyclopedia a one-word anchor is usually an article title, which is about as descriptive as anchor text gets. Google's own guidance asks for anchor text that is descriptive, reasonably concise and relevant, and a single precise noun satisfies all three. Length is not the measure.
Repetition is closer to one. Across the five pages, 79 distinct anchor phrases point at more than one destination. The largest by far is a piece of navigation furniture: an upward arrow character used 50 times on the Wikipedia article as a citation backlink. Then edit, 26 times, and doi, 24 times, both of which are structural rather than editorial. The interesting one is on the Astro homepage, where the phrase view theme appears 27 times and points at 26 distinct destinations. Every one of those links is descriptive of the action and none of them is descriptive of the destination, which is the exact distinction Google's page draws when it asks for text relevant to the page it links to.
That pattern is a template artefact rather than a writing failure, and it is worth naming because it is the most reproducible finding in this post. A component that renders a card with a fixed call to action produces as many identical anchors as there are cards. The fix is not to lengthen the anchor but to move the distinguishing words inside it, so that the theme name travels with the link. For anyone working on a component-driven stack this is a template change in one file, which is why the per stack guides such as the Next.js fix guide and the Shopify one are organised around templates rather than pages.
The destination split is the last count worth stating, because it bounds how much any of this matters. Of the 1,951 links, 1,422 point at the same host, 324 point at another host, and 205 point only at a fragment of the current page. The fragment links are not navigation between documents at all, which means roughly one link in nine on these pages is an in-page control. Counting a page's links without separating those three is how a link total becomes a number that sounds like reach and is not, in the same way that a table count on these pages turned out to be three tables that were all navigation.
Only one of four crawler vendors documents how link text is read
The natural next question is what the AI crawlers do with any of this, and the honest answer is that none of them says. Read on 22 August 2026, OpenAI's crawler documentation, Anthropic's help article on its web crawler and Perplexity's crawler guide contain zero occurrences of the word anchor, zero of the phrase link text, and zero of the phrase alt attribute. Google's page uses the word anchor seventeen times.
That asymmetry is consistent with what the four vendors' pages are for. The three AI vendor pages are access documents: they name user agent tokens, publish IP ranges, and explain how to allow or block a fetch. They describe getting the bytes. Google's page describes what happens to the bytes afterwards, which is a category of documentation the AI crawler vendors have not published at all. We have made the same observation from a different angle several times, most directly when checking whether any crawler vendor documents Retry-After and finding none did.
The practical consequence is that any statement about how ChatGPT or Claude or Perplexity weights a link's text is inference, not documentation, and this site will not publish one. What can be said is narrower and still useful. Anchor text is in the HTML, it survives a fetch without JavaScript, and it is the only place in a document where a human has written a short description of a different document. Whether a given engine uses it, none of them will say. Whether it is there to be used is a fact about your page that you can check today, and that our free tool for seeing what GPTBot sees renders from the raw response rather than from a browser.
There is a second-order point here about the whole category of answer engine optimisation advice. A large amount of it is written as though the extraction behaviour of these engines were published, and it is not. What is published is a robots policy, a set of tokens, and in Google's case a description of link handling that predates the AI crawlers by a decade and still applies to Google Search. Building on the documented part is a slower argument than building on the confident part, and it is the only one that survives the vendor changing something. Our own scanner identity page states what our crawler does for the same reason, which is that a claim you cannot check is not worth making.
| Documentation page | Publisher | States how link text is read | Occurrences of the word anchor |
|---|---|---|---|
| Link best practices for Google | Yes, with two fallbacks | 17 | |
| Overview of OpenAI crawlers | OpenAI | No | 0 |
| Does Anthropic crawl data from the web | Anthropic | No | 0 |
| Perplexity crawlers | Perplexity | No | 0 |
What this does not prove, and what to check on your own pages
The limits are load bearing and they come first. Five pages captured on one day in July is not a sample of the web, and no percentage in this post should be carried off it as a claim about anything other than these five documents. Two of the five are marketing homepages, which are the densest possible source of icon links, so the 4.4 percent figure would move in either direction on a different five. Nothing here was measured against a live site today, no engine was queried, and no crawler was observed reading anything. This is a count over stored HTML, replayed on 22 August 2026 against captures frozen on 15 July 2026.
The most important limit is about the aria-only group. Thirty four links being unnamed by Google's documented chain does not mean 34 links are invisible to any particular system. Extraction pipelines are not obliged to match a search engine's documentation, some of them build an accessibility tree, and none of the AI vendors has published what theirs does. The claim is that the documented path stops, which is checkable, rather than that the link is lost, which is not.
The honest disclosure about this product belongs here too. Lantad does not score anchor text. The composite is weighted 50 percent prose parity, 25 percent access, 15 percent structure and 10 percent schema, and the structure sub-score is seven checks covering the title, the meta description, a single h1, the canonical, heading coverage, oversized text blocks and llms.txt. Not one of them examines a link. A page could carry every one of the failures counted above and lose nothing from its grade, which is a gap in the scale rather than evidence that the gap does not matter, and it is recorded here for the same reason our research page states the limits of its sample instead of burying them.
Three things are checkable on your own pages today without any tool. Open the raw HTML rather than the inspector, because the inspector shows you a browser's assembled view. Find the links whose text is empty and look at what else they carry: a title attribute or an image alt is documented anchor text, and an aria-label alone is not. Then look for one anchor phrase repeated across many destinations, which is the template case and the cheapest to fix. That is a different exercise from checking whether your content loads at all, which is where scroll-loaded content and crawlers that do not scroll bite first, and from checking the structured data that describes the page to a machine. Our methodology page sets out what the scan does measure, and where a signal such as this one sits outside it. Anchor text is the layer people stopped thinking about when generative engine optimisation became the topic, and it is still the only short human-written description of a destination that a machine can read without asking anyone's permission.
- Which links carry no text between the tags? 85 of 1,951 on the five captures. Read the raw HTML, not the inspector, because the inspector shows an assembled view.
- Do the empty ones carry a title or an image alt? Those are the two fallbacks Google's link documentation names. 22 carried a title and 27 carried a non-empty image alt.
- Is an aria-label the only name a link has? Correct for assistive technology and absent from the documented anchor text chain. 34 of the 85 were in this state.
- Is a linked logo or tile using an empty alt? A decorative empty alt on a linked image removes the only documented anchor text that link has. Three of the 85 were this case.
- Is one anchor phrase repeated across many destinations? 79 phrases pointed at more than one destination, and view theme covered 26 of them from one template.
- How many of your links are fragments rather than documents? 205 of 1,951 pointed only at a fragment of the current page, so a raw link total overstates navigation.
Lantad
Published .
Anchor text is the oldest machine-readable summary on the web: a few words, written by a human, saying what is on the other end of a link. It is also one of the few signals a retrieval system can use without running any JavaScript, without a model and without trusting a claim the page makes about itself. So it is worth asking what the links on ordinary pages actually carry, and this post counts that on the only pages this site is entitled to count: the five real captures already frozen in its own fixtures.
Common questions
What does Google use as anchor text when a link has no text in it?
Two fallbacks, both named on Google's link best practices page carrying Last updated 2025-12-10 UTC. If the a element is empty, Google can use the title attribute as anchor text. If the link wraps an image, Google uses the alt attribute of that img element as anchor text. The page names no other fallback and never mentions aria-label.
Does aria-label work as anchor text for search engines and AI crawlers?
It is not documented as anchor text by any of the four crawler vendors Lantad probes. Google's link documentation, read on 22 August 2026, mentions aria-label zero times, and the OpenAI, Anthropic and Perplexity crawler pages contain no description of link text at all. That is a statement about what is published, not proof that any system ignores the attribute. aria-label remains the correct way to name an icon link for assistive technology.
How many links on a real page have no anchor text?
On the five pages Lantad captured and stored on 15 July 2026, 85 of 1,951 links with an href carried no text between the tags, which is 4.4 percent. It ranged from 0 of 133 on the Astro homepage to 32 of 259 on the Webflow homepage. Five pages is not a sample of the web, and two of the five are marketing homepages, which are the densest source of icon links.
Does Lantad's AI visibility score check anchor text?
No. The composite is weighted 50 percent prose parity, 25 percent access, 15 percent structure and 10 percent schema, and the structure sub-score is seven checks covering the title, meta description, a single h1, the canonical, heading coverage, oversized text blocks and llms.txt. None of them examines a link, so a page can carry every failure described in this post without losing a point.
See what AI can read on your site
Run a free scan and get a graded report of exactly what AI crawlers can and cannot read, with ranked fixes.
AI crawler
An AI crawler is an automated bot, such as GPTBot, ClaudeBot, or PerplexityBot, that fetches web pages so an AI system can read, train on, or cite what those pages contain.
Prose Parity
Prose Parity is Lantad's metric for the share of a page's rendered, human-visible text that is present in the raw HTML an AI crawler receives, where 100% means a crawler sees everything a human visitor sees.
Generative Engine Optimization (GEO)
Generative Engine Optimization (GEO) is the practice of structuring and publishing content so that generative AI engines can fetch it, read it in full, and cite it when they answer a question.
173 of 466 images carried alt text a crawler could read
Counted with an HTML parser over five real pages this scanner captured and stored on 15 July 2026, the rendered DOM held 466 img elements: 173 with a non-empty alt attribute, 246 with an explicitly empty one, and 47 with no alt attribute at all. Our own extractor reads none of them.
JavaScript added no new crawl paths, and rendering dropped nine locale links
Counted with an HTML parser over five real pages this scanner captured and stored on 15 July 2026, the raw HTTP response held 991 distinct same-host URLs and the rendered DOM held 982. Three URLs existed only after JavaScript ran, and every one of the three was a rewrite of a link already present. Nine of the twelve that disappeared were one page's translations of itself.
Google deep links into a section, and 55 of 245 headings had an id
Google's snippet documentation, carrying Last updated 2026-04-20 UTC, describes a read more deep link that lands a searcher on a specific section of a page, and names removing the hash fragment from the URL as something that breaks it. Counted with an HTML parser over five real pages this scanner captured on 15 July 2026, 55 of 245 headings carried an id of their own, and 26 headings could not be reached by any element identifier at all.
