---
name: run-weekly-client-seo-audits
description: "Check client sites each week and track what changed. Give the right team clear findings and next steps."
category: Website QA Audit
stage: —
definitive_article: https://blitzmetrics.com/how-to-run-weekly-ai-agent-seo-audits-across-all-your-clients/
status: needs-work
---

# Run weekly client SEO audits

A small site fault can stay live for weeks if no one checks it. This guide helps your team run the same review each week and track the fixes. Start with the clients and pages this job is allowed to cover.

**The path:** Current client scope → Same dated checks → Compare findings → Verified team handoff.

**Use this when:** The agreed weekly audit trigger fires for a verified in-scope client/site list, or the owner authorizes a manual calibration run.

## Inputs
- The current [Client Roster](https://localservicespotlight.com/client-roster/), engagement scope and working run list with exact client, site URLs and existing project thread.
- The agreed checklist version and last audit/evidence for each client, including unresolved issue IDs and owners.
- Real public read access and any required account access; the existing scope for controlled tests, repairs and project-thread posting.
- The actual scheduler/trigger, timezone, persisted run state and failure owner if this is a scheduled run; a manual first run can proceed without claiming a schedule exists.

## First-run prompt

> Use the current roster, exact site/thread list, agreed checklist and previous audits. Run fresh scoped checks, compare issue identities and preserve unknowns. Complete already-authorized repairs or thread posts with receipts, then save the real run state and next owner without inventing scheduler operation or client counts.

## Steps
1. Confirm roster status and engagement before using the run-list row. Active Client work follows its scope; Special Project work needs its explicit scope; Not Active work stops. A spreadsheet row or payment entry is not a replacement for the roster decision.
2. Resolve each exact client site and existing project thread. Load the previous audit, current checklist and last run state. Check for another active worker or duplicate scheduled delivery before starting this execution.
3. Define page coverage and gather fresh canonical public evidence: home page, important services/landing pages and the rest of the agreed scope. Reconcile crawls with known published URLs. Screenshots help visual QA; source reads help tags and links. Neither alone proves all behavior.
4. Apply the current relevant checks for title/description, clear headings, intended robots/indexing, real schema identity, purpose-based image alternatives, sitemap, internal links and content accuracy. Treat 60/160 as house brevity targets, not Google limits; intentional decorative empty alt is valid. Check actual services, hours, staff and location facts against current client records.
5. Record pass, fail, unknown or justified not applicable with exact page, evidence, time and explanation. Actual indexation needs appropriate evidence; eligible or listed-in-sitemap is not indexed. Keep this weekly checklist distinct from the separate seven-component scored SEO exam.
6. Compare issue identities with the prior run. Mark resolved only after the new public check passes; keep recurring and newly found faults separate. Escalate repeat unresolved findings under the source’s Priority 1 convention, preserving the team’s agreed urgency/service commitments rather than inventing a deadline or ranking impact.
7. Draft a concise per-client report: scope, checked date, changed/resolved items, current failures, missing access and named next actions. Post to the exact existing thread when that message is already authorized, using the maintained supported write path. Read back the posted message once and retain the receipt; draft-only work is not delivered.
8. Store this run’s state and next expected check. A real recurring setup needs the configured time and timezone, execution environment, current access, overlap protection and observed first firing/result. Do not assume the article’s historical Friday 9 AM PST, 29 clients or model/runtime claim describes this deployment.

## First-screen, money-page and relationship enforcement

Resolve the canonical fleet registry and Client Roster first; preserve Not Active
stops and site-specific HOLDs. Work from the existing ownership and execution
record so a second agent or clock does not repeat an active rollout. Inventory
all public HTML routes from current sitemap/CMS source. Report total discovered,
measured, reviewed, failed, held and not yet checked separately; a homepage sample
cannot prove every page on a site passes.

Run `ensure-no-text-only-sections-spanning-full-viewport` before scrolling, with
its shared rendered first-screen checker and actual screenshot/source review.
Review priority relationships and buying pages weekly; cover the remaining
eligible routes monthly in bounded batches with the next exact due date recorded.
A relationship refresh needs a newly verified source moment or useful lesson,
not stronger friendship/endorsement wording. Include the public Money Tree and
proof beside material outcome claims. Reconcile the existing relationship,
Money Tree and website audit jobs before registering a schedule. A quiet unchanged
run should not page Dennis; notify on a meaningful change, failure or required
human-only action under the current communication authority.

Every defect keeps URL, observed failure, source/CMS/deployment/rollback state,
owning function, next action, due date and before/after evidence in the existing
record. Apply safe authorized repairs, re-read the ordinary public page, and keep
unavailable source, private evidence, unknown facts and deployment holds explicit.
A merged standard or saved prompt is not live enforcement or observed operation.


## Definition of done (QA checklist)

- [ ] Audited page openings pass `step-7-write-hook-and-establish-context` for actual reader/situation, reason to care, useful outcome and mechanism; exact revision and quoted review are in the existing page inventory, with unsampled pages UNKNOWN and failures assigned to their existing owner

- [ ] Every processed client has current roster/engagement authority and an exact verified destination.
- [ ] The same declared checklist is applied to stated fresh page coverage with truthful unknowns.
- [ ] Prior issues are compared by identity; resolved means newly verified, not merely assigned or saved.
- [ ] Authorized reports have exact thread readback; drafts and failed posts remain separate.
- [ ] Recurring status is backed by actual scheduler/first-run evidence, with historical counts and times not presented as current.

## Example(s)

**Fictional teaching example — no client audit or message ran.** A sample weekly list contains Maple Cycle and a former client. The roster confirms Maple Cycle is in scope and the former client is Not Active, so the latter is skipped.

Last week Maple Cycle had a wrong service description and a broken quote link. This week the served description is correct, but the quote link still fails. The report marks one resolved and one recurring Priority 1 item, with the link owner and evidence. Missing Search Console access remains unknown.

A written report is still draft until its authorized project-thread post is confirmed. A calendar entry alone is not proof that next week’s agent will run.

## Handoff and Content Factory context

Each client’s responsible team receives its actual report and prioritized repair list. The next weekly run verifies public fixes. [Write 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) can use these findings under the client’s agreed cadence; MAA means [Metrics, Analysis, Action](https://blitzmetrics.com/maa/), not automatic separate executions for every report derivative.

This is a supporting quality check for the [Content Factory](https://blitzmetrics.com/content-factory/). Produce gathers real source material; Process makes useful assets; Post places and checks them; Promote distributes suitable work within its own scope. This check does not automatically execute all four stages. Use the actual next step above; catalog neighbors are not prerequisites.

## When this runs

Weekly at the already-agreed time and timezone. Configure a missing schedule only when that recurring setup is actually authorized, then verify its first firing and delivery. Preserve an agreed local-time schedule through daylight-saving handling; do not silently impose the article’s historical PST wording.

## First-run setup and continuity

Open the supplied task file and its linked source. Verify the project’s real inputs, account, access and output folder before work. This Markdown file is a guide; it does not install an app, connect an account, supply a subscription or create a schedule. Carry out work already authorized; do not ask for the same approval again. Keep any unsupplied destination or new action outside that scope clearly pending.

Save source IDs, versions, decisions, checked outputs and next owner in the project tracker. Before a retry, check the saved state and other workers’ changes. A model name does not guarantee memory or a running timer. Repeated work needs an actual configured trigger and durable state; one-off work can be started by the prompt above.

Keep agent media muted with volume zero before playback. If mute cannot be verified, use captions, metadata or still frames. State the limit: silent visual checks do not prove spoken-word accuracy or audio quality. Do not start sound through the user’s speakers unless explicitly asked.

## Write up the real run

For every actual attempt, [write its meta article](https://blitzmetrics.com/meta-article-prompt/) with this recipe and revision, trigger, steps performed, output evidence, measured result, gaps and next owner. Failed, blocked and partial attempts also get a written record. A draft can satisfy writing; publishing it follows the existing job scope.

Keep one stable execution ID across retries and edits. A separately scoped child task may have its own ID linked to its parent. Writing the parent’s meta record is part of that run, not an endless new chain. The [recipe and meta-article guide](https://localservicespotlight.com/meta-articles/) explains this distinction. Teaching examples are not real executions and must not enter the run count.


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

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

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 2, gating 3 (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

- Canonical article: https://blitzmetrics.com/how-to-run-weekly-ai-agent-seo-audits-across-all-your-clients/
- Exact task: [Run weekly client SEO audits](https://local-service-spotlight.github.io/task-library/?task=run-weekly-client-seo-audits#task-run-weekly-client-seo-audits)
- Writing standard: [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Website QA Audit](https://blitzmetrics.com/website-qa-audit/)
- [Google title links](https://developers.google.com/search/docs/appearance/title-link)
- [Google snippets](https://developers.google.com/search/docs/appearance/snippet)
- [W3C image text alternatives](https://www.w3.org/WAI/tutorials/images/decision-tree/)
- [Google robots meta and headers](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag)

## Review and evidence still needed

The source contributor status is preserved. It is not certification of this draft or proof of account access, completed work or a live outcome. The worked example teaches the method and is explicitly fictional.
- The real client roster/list, previous audits, approved delivery scope, scheduling configuration and first firing require the operating project.
- The owned article still contains historical-looking client/model/time claims and stale technical clauses; these guide corrections need reconciliation with that article’s owner.
- No independently verified completed execution or working scheduler is added by this authored needs-work candidate.