What does "links do not have descriptive text" mean?

Lighthouse found one or more anchors whose text matches a blocklist of generic phrases such as "click here", "learn more", "here", or "more". The link works, but its text tells search engines and screen reader users nothing about where it goes.

Does aria-label fix the link-text audit?

No. Unlike the link-name accessibility audit, link-text reads the anchor's actual text content, so an aria-label does not change the result. The fix is rewriting the visible words to describe the destination.

Is "learn more" bad for SEO?

It wastes a signal rather than causing a penalty. Anchor text tells search engines what the linked page is about; "learn more" carries no information. "Learn more about our returns policy" passes the audit and passes the signal.

How is link-text different from link-name?

link-name is an accessibility audit that fails when a link has no accessible name at all, typically an icon-only link. link-text is an SEO audit that fails when the text exists but is generic. A link can pass one and fail the other.

Links do not have descriptive text: how to fix it

Quick answer: This audit fails when link text is generic: phrases like "click here", "learn more", or "more" that say nothing about the destination. Fix it by rewriting each anchor to name what it points to. Descriptive link text helps search engines understand the linked page and helps screen reader users who navigate by link list.

This Lighthouse audit fails when the page contains links whose text is generic: "click here", "learn more", "more", "here". The links work. The problem is what the words carry, which is nothing. Anchor text is one of the oldest relevance signals on the web: it tells search engines what the linked page is about, and it tells a screen reader user scanning a list of links where each one goes. A page full of "learn more" anchors withholds that signal from every link on it.

TL;DR

What: One or more <a> elements have text matching a blocklist of generic phrases.
Why it matters: Anchor text is a relevance signal for the linked page, and the primary navigation cue for screen reader users browsing by link list.
Fix: Rewrite each anchor to name its destination. "Read the shipping policy", not "click here".

What does the link-text audit check?

Lighthouse collects the crawlable <a> elements on the rendered page (links with a real href; javascript: and mailto: links are skipped) and compares each anchor's text content against a blocklist of generic phrases. If any link's text matches, the audit fails and lists the offending anchors.

The English blocklist includes:

click here
click this
go
here
this
start
right here
more
learn more

Lighthouse ships localized blocklists too, so "hier klicken" and "cliquez ici" fail the same way. The comparison is against the anchor's text after trimming, so <a href="/pricing">More</a> fails while <a href="/pricing">More pricing details</a> passes.

One detail that surprises people coming from the accessibility audits: this audit reads the anchor's text content, not its accessible name. An aria-label that names the destination will satisfy the link-name accessibility audit, but it does not change the outcome here. The fix for link-text is always rewriting the visible words.

Why does descriptive link text matter for SEO?

Search engines use anchor text to understand the page a link points to. It is a signal you control on every internal link, and it is free: rewriting "click here to see our shipping rates" as "see our shipping rates" moves the signal onto the link without adding a word to the page.

Google's own Search Essentials guidance on links says the same thing directly: write anchor text that describes the destination, because Google uses it to understand the linked page. Ten internal links labelled "learn more" tell Google ten times that the destinations are about nothing in particular.

It also matters beyond rankings:

Screen reader users navigate by link list. VoiceOver and NVDA can pull up every link on the page as a flat list, out of context. Ten "learn more" entries in that list are indistinguishable. This is the concern behind WCAG SC 2.4.4 Link Purpose and the stricter SC 2.4.9.
AI extraction. Assistants and answer engines resolve links the same way crawlers do: by what the anchor says. A link named for its destination is a link an AI can cite correctly.

How do I fix "links do not have descriptive text"?

Rewrite the anchor so the words name the destination. The most reliable pattern: move the link onto the noun phrase that is usually already sitting in the sentence.

<!-- FAILS: the sentence has the information, the link doesn't -->
<p>Our full shipping policy is available. <a href="/shipping">Click here</a>.</p>

<!-- FIXED: link the words that describe the destination -->
<p>Read our <a href="/shipping">full shipping policy</a>.</p>

<!-- FAILS: card pattern with a bare "learn more" -->
<a href="/plans/pro" class="card-cta">Learn more</a>

<!-- FIXED: name the thing -->
<a href="/plans/pro" class="card-cta">Learn more about the Pro plan</a>

<!-- FAILS: bare "more" pagination-style link -->
<a href="/blog?page=2">More</a>

<!-- FIXED -->
<a href="/blog?page=2">More articles</a>

Guidelines that keep the rewrite honest:

Name the destination, not the action. "Download the pricing PDF" beats "download now".
Keep it short. A few words. The anchor is a label, not a sentence.
Make anchors unique when destinations differ. Two links labelled "shipping policy" should go to the same place.
Front-load the distinctive word. Screen reader users skim link lists alphabetically and by first word.

How do I fix this in React, WordPress, or Shopify?

React / Next.js

Card and CTA components are the usual source, because the label is a prop with a default:

// FAILS: every card renders the same generic CTA
<ArticleCard href={post.url} cta="Learn more" />

// FIXED: derive the label from the content
<ArticleCard href={post.url} cta={`Read: ${post.title}`} />

If the design insists on a short visible label, keep the visible text descriptive enough to pass and put the detail in the surrounding heading, not in an aria-label (which this audit ignores).

WordPress

The classic offender is the theme's "read more" / "learn more" excerpt link and button blocks pasted with default text. Check:

Button and card blocks. Editors paste them with "Learn more" and move on. Make the destination part of the label.
Post excerpt links. Many themes let you change the more-link text; include the post title or category ("Continue reading: {title}") via the theme's filter (the_content_more_link or excerpt_more).
Page builder CTAs. Builder templates ship "Click here" defaults. Audit the rendered page, not the builder preview.

Shopify

In a scan of 269 production storefronts, link-text failed on 23% of them (62 of 269), almost always from theme sections with default copy:

Footer and announcement links labelled "Learn more" pointing at policies and shipping pages. Name them: "Shipping rates", "Returns policy".
Collection and banner CTAs. Section presets ship with "Learn more" / "More" placeholder text that survives into production. Replace with the collection or product name: "Shop the winter collection".
Multi-column "content" sections where every column's link says "Learn more". The heading above each column already has the right words; put them in the link.

The fix lives in the theme editor's section settings in nearly every case; no Liquid edit required.

What link-text pitfalls should I avoid?

Do not fix it with aria-label. It will not pass this audit (the audit reads text content), and hiding the real label from sighted users was never the goal anyway.
Do not swing into keyword stuffing. "Best cheap fast shipping policy free returns 2026" as anchor text reads as spam to users and to Google. Name the destination in plain words.
Do not write paragraph-length anchors. Linking an entire sentence dilutes the signal and is harder to skim. Link the noun phrase.
Do not leave ten identical anchors pointing at ten different pages. Each passes individually, but the link list is still useless and the signal is still muddy. Differentiate them.
Do not hide descriptive text with CSS to preserve a short visual label. display: none text is removed from the accessibility tree and may be ignored by crawlers. If the visible label must stay short, make those short words descriptive.

How do I verify the fix?

Re-run Lighthouse or PageSpeed Insights. The link-text audit should move into "Passed audits".
Read the page's links as a list: in VoiceOver (VO+U, arrow to Links) or NVDA (Insert+F7). If you can tell where every link goes without seeing the page, the text is descriptive.
Grep your codebase or templates for the blocklist phrases ("click here", "learn more") to catch instances on pages Lighthouse did not audit.
For internal links, check GSC's Links report after a few weeks: better anchors improve how Google groups and describes your internal pages.

Links do not have a discernible name, the accessibility sibling: no name at all vs a generic one
Document does not have a meta description, the other free SERP signal
Document does not have a title element, the strongest on-page signal
Canonical tag, where those anchor signals consolidate

Audit your URL at https://lighthouse-md.com.

Audit your page now

Paste your URL, get scores plus a CLAUDE.md plan for Claude Code.

Run audit →