---
name: use-proper-anchor-text-3-6-words-descriptive
description: "Help readers know where a link will take them."
category: SEO & Content Architecture
stage: —
definitive_article: /internal-linking
status: complete
---

# Use proper anchor text (3–6 words, descriptive)

Help readers know where a link will take them. This guide replaces vague link words with clear names and useful phrases. Start with the links you plan to change and read each page they open.

**The path:** Anchor and context list → Destination promise check → Natural wording → Rendered link review

**Start when:** A draft or bounded existing-page audit contains vague, misleading or needlessly padded link text.

## Inputs

- The current source pages and a bounded anchor report, with exact href, surrounding sentence and source revision.
- The real destination content and [Goals, Content, Targeting: the result, source material and people served](https://blitzmetrics.com/gct-business-strategy/), plus [Choose the right entity destination](https://local-service-spotlight.github.io/task-library/?task=follow-entity-linking-decision-tree#task-follow-entity-linking-decision-tree) for identity and owned-explanation routes.
- The supported content source/builder, edit authority and relevant existing media/IDs to preserve.

## Steps

1. List the actual links in scope and read their surrounding copy. Flag vague words such as “click here,” a bare URL in ordinary explanatory prose, misleading names or excessive keyword repetition. Keep functional citations, legal identifiers and platform controls in their proper context instead of blindly replacing every URL string.
2. Read each destination and state what the reader gets there. Check that its person, company, topic or action matches the link’s promise. A link that opens a different page needs a destination decision before better wording can make it useful.
3. Write a concise descriptive phrase, usually three to six words when natural. Use the actual entity name where it is clearer, even if shorter. This is a house writing preference, not a Google minimum or maximum, and padding “Dennis Yu” into a longer phrase can make the reference less accurate.
4. Place the wording in a sentence that explains why the next page helps. Keep it natural for the author and reader. Reuse a correct name consistently where appropriate; do not force synonyms merely to make anchors look varied, and do not overload a phrase with search terms.
5. Preserve the difference between an owned explanation, a primary evidence citation and a necessary account or download action. Label the exact purpose and use its appropriate destination. A general method link cannot fulfill a button’s promise to open the real sign-in page.
6. Apply the narrow wording edit through the maintained source and inspect the result. Ensure that the clickable span includes the intended words, punctuation remains correct, and surrounding text, media and identifiers are unchanged. Check keyboard use and responsive layout for any affected link or button.
7. After authorized release, open the normal page and follow the edited link. Save the exact before/after anchor, href, revision and public evidence. Report resolved, held and intentionally retained cases within the stated scope; do not claim a whole-site cleanup from a sample or a failed fetch.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] Each revised phrase predicts the actual destination and fits the surrounding sentence.
- [ ] House word-count preferences do not distort real names, necessary actions or useful citations.
- [ ] Exact source and public anchor checks are saved, and scope limits and exceptions are explicit.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional repair guide says “click here” before a link to its leak test method. The editor changes it to “check a roof leak” and reads the target to confirm the promise. A nearby link named for a two-word person remains that person’s actual name. Both are clear, even though only one uses the usual three-to-six-word phrase.

## Handoff and Content Factory context

[Check the placed links](https://local-service-spotlight.github.io/task-library/?task=step-5-qa-links-against-google-guidelines#task-step-5-qa-links-against-google-guidelines) receives the exact anchor changes and known exceptions. [Measure the accepted change set](https://local-service-spotlight.github.io/task-library/?task=step-6-measure-and-iterate-with-maa#task-step-6-measure-and-iterate-with-maa) receives the release log only where an actual measurement question exists.

This task supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Identity, proof, access or coordination can support several stages. Use the real inputs and receiving owner above; this task does not create unrelated transcripts, clips or ads merely because the diagram has four stages.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `computer` — Logged-in UI (Meta Ads Manager, Descript, GSC, wp-admin when REST is blocked). Requires a supported browser tool and the right account access.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/internal-linking/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=use-proper-anchor-text-3-6-words-descriptive#task-use-proper-anchor-text-3-6-words-descriptive)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

### Primary method references

- [Google’s descriptive anchor guidance](https://developers.google.com/search/docs/crawling-indexing/links-crawlable)

## Review and evidence still needed

The inherited contributor status is `complete`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.