---
name: step-5-qa-links-against-google-guidelines
description: "Check that each new link helps readers reach the right page."
category: SEO & Content Architecture
stage: —
definitive_article: /internal-linking
status: complete
---

# Step 5: QA links against Google guidelines

Check that each new link helps readers reach the right page. This guide tests the words, the page they open and the reason to click. Start with the exact list of links that changed and their live pages.

**The path:** Exact changed links → Meaning and destination checks → Repairs or held rows → Accepted log

**Start when:** Step 4 has saved or released a defined set of links and supplied the actual change log.

## Inputs

- [Place the accepted links](https://local-service-spotlight.github.io/task-library/?task=step-4-create-links-with-proper-anchor-text-and-placement#task-step-4-create-links-with-proper-anchor-text-and-placement) log with source/target, anchor, surrounding text, exact revision and save/public state.
- The accepted [Goals, Content, Targeting: the result, source material and people served](https://blitzmetrics.com/gct-business-strategy/) and current owning target pages, plus normal public access to the changed source pages.
- The maintained [internal-linking method](https://blitzmetrics.com/internal-linking/) and current Google primary link guidance.

## Steps

1. Start from the exact changed-link log and read each link in its actual normal page context. Compare it with the saved source, not just a preview or cached screenshot. A stale public copy or inaccessible page is a specific verification gap; do not approve it because the CMS raw text is correct.
2. Check the anchor’s promise against the destination. It should be concise, descriptive and natural; the house three-to-six-word preference is not a Google word-count rule. A real two-word name can be correct, and repeating an accurate name is not automatically keyword stuffing.
3. Check that the surrounding sentence gives a useful reason to follow the link and remains factually true. Confirm the named person, company, method or offer matches. Owned explanatory links must not replace a necessary primary citation, sign-in or download destination with a general guide.
4. Inspect placement and link behavior. Ordinary crawlable links use real anchors with destinations, and readers must be able to see and use them. Contextual body links are this change set’s purpose; useful menu/footer navigation is not inherently manipulative. Hold hidden, misleading or unrelated link schemes.
5. Review volume by reader usefulness rather than a fixed links-per-word ratio. Remove redundant or forced additions where they add no value. Google states no ideal link count; a page with many relevant sources and a short page with few links need different judgments.
6. Follow each changed destination and record actual responses and redirect meaning. Correct a stale internal alias when the verified final target serves the same purpose; do not rewrite an intentional external evidence link blindly. Handle removed content with a relevant replacement or the proper reviewed removal behavior, never an arbitrary redirect.
7. Repair in-scope defects through the same maintained source rail and repeat only the affected checks. Save accepted, failed and held rows with exact evidence and owners, plus any wider issues discovered outside this scope. Pass the verified change set to measurement without declaring full-site compliance from a limited link review.

## 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 accepted changed link has an accurate anchor, useful context, correct identity and actual destination check.
- [ ] The review distinguishes Google guidance from house preferences and finds no hidden or irrelevant link scheme in the changed set.
- [ ] Source/public mismatches, failed links and out-of-scope defects retain their real states and owners.
- [ ] 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 review checks eight new links. Seven point to the intended pages. The eighth uses a service name but now redirects to a general home page, so it is held until the owner confirms a relevant destination. The report accepts seven and names one blocker; it does not declare the entire site fixed from this small check.

## Handoff and Content Factory context

[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 accepted URLs, release dates, corrections and limitations. The page owner receives any held destination or source problem before that row is called done.

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:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **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=step-5-qa-links-against-google-guidelines#task-step-5-qa-links-against-google-guidelines)
- [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 current link best practices](https://developers.google.com/search/docs/crawling-indexing/links-crawlable)
- [Google’s link spam policies](https://developers.google.com/search/docs/essentials/spam-policies)

## 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.