---
name: step-6-measure-and-iterate-with-maa
description: "See what changed when your new links went live."
category: SEO & Content Architecture
stage: —
definitive_article: /internal-linking
status: complete
---

# Step 6: Measure and iterate with MAA

See what changed when your new links went live. This guide compares real page data to help you choose what to do next. Start with the checked link list, its dates and the data you can access.

**The path:** Checked changes + baseline → Comparable page measures → Evidence-led analysis → Owned next action

**Start when:** A bounded linking change set has passed QA and has a defined measurement window and owner.

## Inputs

- [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) accepted log with source/target URLs, release dates, held rows and exact source revision.
- Pre-change measurements when available, actual search/analytics access, consistent filters, timezone and comparable observation dates.
- The site’s agreed goals, actual offer actions and [Metrics, Analysis, Action: what happened, why and what to do](https://blitzmetrics.com/maa/) reporting format; known concurrent content, ad or site changes.

## Steps

1. Define the changed URL set, question, date range and success measure before interpreting numbers. Ideally save the baseline before Step 4 releases links. If that was missed, record the gap and use only available historical data; do not reconstruct a confident baseline from memory or a different site.
2. Collect comparable page/query search measures such as clicks, impressions and average position from the actual connected source. Collect relevant sessions or observed inquiries only when those systems are accessible and their definitions are known. Keep disconnected, filtered or delayed data unknown rather than zero.
3. Use consistent properties, periods, filters and URL handling for before/after comparisons. Keep search measures, sessions, link clicks and business outcomes separate; one is not a substitute for another. Note low sample size, partial weeks, seasonality and concurrent page, campaign or site changes.
4. Check whether the intended paths are still live and useful, especially former orphans and important offer links. A new crawl can establish incoming connections; it does not prove search indexing or a sale. Indexing observations and rank measures require their own source and date.
5. Write the analysis in terms the evidence supports. A rise after the edits is an observed association, not proof that one anchor caused it. Explain plausible competing causes and what further observation would distinguish them. Do not claim to identify which individual link “did the work” from a page-level traffic total.
6. Choose a bounded next action tied to the finding: repair a broken relevant path, improve a weak source, inspect a missing data source, retain a useful link or wait for adequate data. Do not change anchors or remove helpful links simply because a short window shows no traffic gain.
7. Write the report with actual metrics, interpretation, action owner, due point and evidence links. Finish this scoped review when its real checks pass, or leave it blocked on a named dependency. A continuing program uses its existing agreed job and review cadence; this recipe does not create a schedule or turn one execution into an endless counted loop.

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

- [ ] Dates, URL scope, metric definitions and access gaps make the comparison reproducible.
- [ ] Observed changes are separated from causal claims, and traffic is not mislabeled revenue.
- [ ] The action follows evidence and has an owner; the bounded execution and recurring program remain distinct.
- [ ] 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 sees more search clicks in the two weeks after six links changed. A new article and a paid campaign also launched that week, and inquiries are not connected. The report states the click change, notes those limits and keeps the helpful links. It assigns a later comparable review rather than claiming the links generated sales.

## Handoff and Content Factory context

[Prepare the weekly MAA report](https://local-service-spotlight.github.io/task-library/?task=submit-weekly-maa-report-every-friday#task-submit-weekly-maa-report-every-friday) receives the sourced findings and next owners. [Plan relevant links and orphan repairs](https://local-service-spotlight.github.io/task-library/?task=step-3-identify-money-pages-and-orphan-pages#task-step-3-identify-money-pages-and-orphan-pages) receives only supported new linking actions; missing measurements go to the actual data owner.

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:** 4/5 `●●●●○` — frequency 4, revenue 4, gating 2 (runs every factory cycle or weekly; creates the asset ads amplify)
- **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-6-measure-and-iterate-with-maa#task-step-6-measure-and-iterate-with-maa)
- [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

- [Search Console performance report definitions](https://support.google.com/webmasters/answer/7576553?hl=en)

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