How to QA a Personal Brand Website

START

---
name: audit-internal-links-between-all-blog-posts
description: Checks that every blog post links to at least one other post and a service page, so no content is orphaned and link equity flows toward money pages.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Audit internal links between all blog posts

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — orphaned posts earn no rankings and pass no authority.

## Inputs
- WordPress admin access, ideally with LinkWhisper installed (its internal links report does the counting)
- Alternatively a Screaming Frog crawl with inlink/outlink counts per URL
- The site's list of money/service pages
- The audit report/spreadsheet for logging results

## Steps
1. Pull the internal links report from LinkWhisper (or Screaming Frog's inlinks/outlinks columns) covering every published post.
2. Flag every post with zero outbound internal links to other posts — each post must link to at least one related post.
3. Flag every post that links to no service/money page — content exists to route readers toward the offer.
4. Flag orphans from the other direction: posts that no other page links TO (zero internal inlinks).
5. Check link placement: links belong in body copy with descriptive 3–6 word anchors, not dumped in a "related posts" widget alone.
6. Log the per-post link counts and the orphan/fix list in the audit report.

## Definition of done (QA checklist)
- [ ] Every published post links to at least one other post AND at least one service page in body content
- [ ] Zero orphan posts — every post has at least one internal inlink
- [ ] Per-post link table logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent Fable 5 agent (or comparable OpenAI/Google long-horizon model) computes inlink/outlink counts for every published post each run, inserts the missing post-to-post and post-to-service links in body copy with descriptive anchors, and re-crawls until zero orphans remain and every post meets both link minimums.
Memory keeps the per-post link graph, so re-runs only rework new posts and posts whose links changed — and every newly published post automatically re-opens the orphan check.
Each run logs one worked example to ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /seo-tree (leaves → branches → trunk structure) · /blog-posting-guidelines · previous: verify-email-opt-in-form-exists-and-works · next check: verify-entity-linking-follows-decision-tree

END

START

---
name: check-all-cta-buttons-lead-to-correct-destinations
description: Click-tests every call-to-action button on the site to confirm each routes to the destination its copy promises, keeping the conversion path unbroken.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Check all CTA buttons lead to correct destinations

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — a CTA that 404s or routes to the wrong page is a lead silently lost.

## Inputs
- Site URL plus a full page list (XML sitemap or crawl export)
- The intended destination map (which CTA should go where — booking page, contact form, lead magnet, phone)
- Desktop and mobile browsers for click-testing
- The audit report/spreadsheet for logging results

## Steps
1. Inventory every CTA button across the site: hero, section CTAs, header button, footer, in-post CTAs, and popups.
2. Click each one and record the actual destination URL; fail anything returning 404, the homepage, a stale landing page, or a placeholder anchor (`#`).
3. Match destination to promise: "Get a Quote" must land on the quote/contact form, "Book a Call" on the live scheduler, "Download" on the actual opt-in — not a generic page.
4. Test click-to-call CTAs on a real phone — the `tel:` link must dial the current business number.
5. Repeat the clicks on mobile, where overlays and sticky bars often break or cover buttons.
6. Log every CTA with its label, location, expected vs actual destination, and pass/fail in the audit report.

## Definition of done (QA checklist)
- [ ] 100% of CTAs route to their promised, working destination on desktop and mobile — zero 404s, placeholders, or mismatches
- [ ] Click-to-call links dial the correct current number
- [ ] CTA inventory with expected-vs-actual logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent agent (Fable 5 / comparable OpenAI or Google models) inventories every CTA on every page — including popups and sticky bars — resolves each destination at desktop and mobile widths, and loops fix-retest until 100% match their promised destination with zero 404s or placeholder anchors.
Memory keeps the CTA inventory with expected-vs-actual per page, so re-runs only retest changed pages, new CTAs, and previously failing buttons.
Each run logs one worked example to ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing (clear conversion path) · previous: verify-featured-images-unique-per-blog-post · next check: verify-email-opt-in-form-exists-and-works

END

START

---
name: check-each-homepage-section-includes-relevant-image
description: Walks the homepage section by section to confirm each one carries a contextually relevant image, so no part of the page falls back to a wall of text.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Check each homepage section includes relevant image

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — every scroll-stop on the homepage needs a visual that earns its place.

## Inputs
- Homepage URL on desktop and mobile
- The no-stock and alt-text findings from earlier checks (reuse, don't redo)
- The audit report/spreadsheet for logging results

## Steps
1. Scroll the full homepage and list every distinct section (hero, services, about, social proof, lead magnet, video, CTA, footer) in order.
2. For each section, record whether it contains an image or visual element (photo, video embed, real screenshot, diagram — decorative background tints don't count).
3. Judge relevance per section: the visual must depict that section's subject — the services section shows the actual work, the about section shows the actual person.
4. Fail sections with no visual at all, and sections whose image is filler (generic texture, icon-only decoration, or an unrelated photo).
5. Check the mobile view — sections sometimes drop their images responsively, which fails the check on mobile even if desktop passes.
6. Log the section-by-section table with verdicts in the audit report.

## Definition of done (QA checklist)
- [ ] 100% of homepage sections contain at least one contextually relevant image or visual on desktop AND mobile
- [ ] Zero sections relying on filler or unrelated imagery
- [ ] Section-by-section table logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
Run persistent (Claude Fable 5 or comparable OpenAI/Google models), the agent enumerates every homepage section in the DOM, verifies a relevant visual renders in each on desktop AND mobile, and loops add-recheck until zero sections fail either viewport — then extends the same section-by-section pass to every key landing page.
Memory keeps the section-to-image table, so re-runs only re-judge sections that changed since the last pass.
Each run logs the table as a worked example in ## Example(s) so the library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (image standards) · previous: verify-hero-section-contains-real-photo-of-person · next check: verify-social-proof-photos-present

END

START

---
name: check-favicon-is-set
description: Confirms a proper branded favicon is uploaded and rendering in browser tabs, bookmarks, and search results instead of a blank or default icon.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Check favicon is set

**Use this when** running Layer 1 (Digital Plumbing Checks) of the Website QA Audit — a missing favicon is the small detail that signals an unfinished site.

## Inputs
- Site URL
- A desktop browser and a mobile browser for visual confirmation
- WordPress admin access (Appearance → Customize → Site Identity → Site Icon) if a fix is needed
- The audit report/spreadsheet for logging results

## Steps
1. Load the site in a desktop browser tab and confirm a branded icon appears — not the browser's default blank-page glyph.
2. Fetch `/favicon.ico` directly and view page source for the icon link tags; confirm at least one icon resource returns 200, not 404.
3. Confirm the icon is actually the brand (logo mark or the person's recognizable mark), not the WordPress default, the theme developer's logo, or the hosting company's icon.
4. Check on mobile by saving the site to the home screen or viewing the tab switcher — the icon must render legibly at small sizes.
5. Google the brand name and check whether the favicon shows next to the site in mobile search results (Google pulls it from the same icon).
6. Log pass/fail with a screenshot of the tab icon in the audit report.

## Definition of done (QA checklist)
- [ ] A branded favicon renders in desktop tabs and mobile, with the icon resource returning 200
- [ ] The icon is the owner's brand — not a default, theme, or host placeholder
- [ ] Screenshot evidence logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
Even a small check runs to exhaustion on a persistent agent (Fable 5 or comparable OpenAI/Google models): it fetches every declared icon resource — favicon.ico, apple-touch-icon, manifest icons — until each returns 200, confirms the rendered icon is the brand at every size, and loops on any 404 or default glyph until the fix sticks.
Memory records the passing icon set and file hashes, so a re-run instantly detects a theme update silently swapping the icon back to a default.
Each run logs a worked example to ## Example(s) so the library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing · previous: verify-person-schema-with-sameas-links · next check: ensure-robots-meta-not-blocking-indexing

END

START

---
name: check-for-broken-links
description: Scans the entire site with a link checker to find and fix every broken internal and external link before visitors or crawlers hit them.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Check for broken links

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — broken links bleed trust, crawl budget, and link equity.

## Inputs
- Site URL with crawl permission
- A link checker: Screaming Frog (Response Codes report), Ahrefs Site Audit, or the Broken Link Checker plugin
- The audit report/spreadsheet for logging results

## Steps
1. Crawl the full site with the link checker and pull all URLs returning 4xx or 5xx, plus links to them (the "inlinks" view shows where each broken link lives).
2. Separate internal breaks (your pages linking to your dead pages) from external breaks (links to third-party pages that died).
3. For each internal break, decide the fix: update the link to the right live URL, or 301-redirect the dead URL if other sites also point at it.
4. For each external break, relink to the current location of the resource or remove the link.
5. Flag redirect chains and loops while you're in the Response Codes report — they waste crawl budget even though they "work."
6. Re-crawl after fixes to confirm zero remaining 4xx/5xx, and log before/after counts in the audit report.

## Definition of done (QA checklist)
- [ ] Re-crawl shows zero broken internal links and zero broken external links site-wide
- [ ] No redirect chains longer than one hop on internal links
- [ ] Before/after crawl evidence logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
This is the canonical persistent-agent loop (Fable 5 or comparable OpenAI/Google models): crawl every URL, fix every 4xx/5xx and redirect chain, re-crawl, and repeat until the full-site crawl returns zero broken links — external links included, which decay continuously and make any single clean pass temporary.
Memory holds the last crawl's verdict per link, so each re-run focuses on new links and previously fixed ones, self-verifying that fixes held.
Each run logs before/after counts as a worked example in ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /seo-audit · previous: verify-entity-linking-follows-decision-tree · next check: verify-footer-includes-social-links-and-secondary-nav

END

START

---
name: check-lead-magnet-section-has-visual-mockup
description: Confirms the lead magnet offer is shown with a visual mockup or preview image, because an offer people can see converts better than a text link.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Check lead magnet section has visual mockup

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — a lead magnet with no visual looks like nothing is actually being given away.

## Inputs
- Site URL and the location of the lead magnet offer(s) (homepage section, popup, blog sidebar)
- The actual lead magnet file (to confirm the mockup honestly represents it)
- The audit report/spreadsheet for logging results

## Steps
1. Locate every place the lead magnet is offered on the site.
2. Confirm each placement includes a visual representation: a cover mockup, device-screen preview, or first-page screenshot — not just a headline and button.
3. Open the actual lead magnet and verify the mockup matches it — same title, same content; a mockup of a different or hypothetical asset fails.
4. Check the mockup's rendering quality: sharp at the displayed size on desktop and mobile, not stretched or pixelated.
5. Confirm the visual sits adjacent to the opt-in form/CTA so the offer and the action are one unit.
6. Log each placement, its visual, and verdict in the audit report.

## Definition of done (QA checklist)
- [ ] Every lead magnet placement includes a visual mockup or preview that accurately represents the real asset
- [ ] Mockup renders cleanly on desktop and mobile next to its opt-in CTA
- [ ] Placement verdicts logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
Run on a persistent agent (Claude Fable 5 or comparable OpenAI/Google models), every lead magnet placement on the site gets checked each run — homepage section, popups, sidebars — confirming a sharp, accurate mockup sits beside the opt-in on desktop and mobile, looping until all placements pass.
Memory pairs each placement with the asset version it represents, so a re-run flags drift the moment the lead magnet is updated but the mockup isn't.
Each run logs one worked example to ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: sibling check: verify-email-opt-in-form-exists-and-works (the form behind this visual) · next check: verify-at-least-one-video-embed-on-homepage

END

START

---
name: check-meta-description-under-160-chars
description: Audits every page's meta description for the under-160-character limit and keyword relevance so search snippets display fully and earn the click.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Check meta description under 160 chars

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — the meta description is the ad copy that wins or loses the click in search results.

## Inputs
- WordPress admin access with RankMath active (or a Screaming Frog crawl export of meta descriptions)
- Each page's focus keyword for the relevance check
- The audit report/spreadsheet for logging results

## Steps
1. Crawl the site with Screaming Frog (or export via RankMath) to get every meta description and its character count in one table.
2. Flag every description over 160 characters (truncates in results) and every page with no description at all (Google improvises one).
3. Confirm each description contains or closely matches the page's focus keyword — Google bolds the match, which lifts click-through.
4. Read each one as ad copy: it should state what the page delivers and for whom, not restate the title or read as filler.
5. Flag duplicate descriptions across pages — each page needs its own.
6. Log every failure with page URL, current description, and character count in the audit report.

## Definition of done (QA checklist)
- [ ] 100% of indexed pages have a unique meta description of 160 characters or fewer
- [ ] Every description includes or closely matches the page's focus keyword
- [ ] Full description table logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
On a persistent agent (Claude Fable 5 / comparable OpenAI or Google models), this becomes a full-inventory loop: crawl every indexed page's description, flag over-160s, blanks, duplicates, and keyword misses, rewrite, re-crawl, and repeat until every page carries its own compliant description.
Memory stores the passing description per URL, so each re-run diffs against the last pass and only reworks changed or new pages.
Each run logs one before/after example to ## Example(s) so the audit library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (meta description rules) · previous: check-seo-title-under-60-chars-with-focus-keyword · next check: verify-rank-math-score-above-70-on-every-page

END

START

---
name: check-schema-connects-to-all-verified-profiles
description: Confirms the schema sameAs array covers every active, verified profile the owner has — the completeness pass that closes the entity loop for Google.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Check schema connects to all verified profiles

**Use this when** closing Layer 3 (Authority & Trust Checks) of the Website QA Audit — Layer 1 proved schema exists; this check proves it's complete.

## Inputs
- The verified-profile inventory built during this audit (social links check + GBP check)
- Google Rich Results Test and validator.schema.org
- WordPress admin access to RankMath (where sameAs URLs are managed on standard builds)
- The audit report/spreadsheet for logging results

## Steps
1. Assemble the master list of the owner's verified, active profiles confirmed earlier in this audit: LinkedIn, Facebook, Instagram, YouTube, Twitter/X, plus the Google Business Profile listing.
2. Run the homepage through the Rich Results Test and extract the current sameAs array from the Person/Organization markup.
3. Diff the two lists: every verified active profile must appear in sameAs — record each missing profile.
4. Check the reverse direction: flag sameAs entries pointing to dead, abandoned, or wrong-person profiles for removal.
5. Apply fixes in RankMath's schema/sameAs settings and re-run the Rich Results Test to confirm the updated array parses with zero errors.
6. Log the final sameAs list against the profile inventory in the audit report, then compile the full three-layer audit findings for delivery.

## Definition of done (QA checklist)
- [ ] sameAs array matches the verified-profile inventory one-to-one — no missing profiles, no dead or wrong entries
- [ ] Updated markup re-validates with zero errors in the Rich Results Test
- [ ] Final diff logged and the complete 36-check audit report delivered, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent Fable 5 agent (or comparable OpenAI/Google model) re-diffs the sameAs array against the full verified-profile inventory every run — every entry fetched live, every profile accounted for — and loops update-revalidate until the two lists match one-to-one with zero validator errors.
Memory carries the profile inventory forward from the sibling checks, so any profile added, renamed, or abandoned anywhere in the audit re-opens this completeness pass automatically.
Each run logs the final diff as a worked example in ## Example(s) so the audit library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing (schema implementation) · Layer 1 sibling: verify-person-schema-with-sameas-links · siblings: check-social-profiles-linked-and-prominent, verify-google-business-profile-is-verified

END

START

---
name: check-seo-title-under-60-chars-with-focus-keyword
description: Audits every page's SEO title for the under-60-character limit and focus keyword inclusion so titles display fully in search and rank for the right terms.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Check SEO title under 60 chars with focus keyword

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — truncated or keyword-less titles waste the strongest on-page ranking signal.

## Inputs
- WordPress admin access with RankMath active (or a Screaming Frog crawl export of title tags)
- The focus keyword assigned to each page (from RankMath's per-post setting)
- The audit report/spreadsheet for logging results

## Steps
1. Crawl the site with Screaming Frog (or export titles via RankMath) to get every page title and its character count in one table.
2. Flag every title over 60 characters — these truncate with "…" in Google results.
3. For each page, open the RankMath snippet editor and confirm the focus keyword is set AND appears in the SEO title, preferably near the front.
4. Flag duplicate titles — two pages with the same title compete with each other.
5. Flag empty or auto-generated titles (raw "Page Title – Site Name" defaults with no keyword intent).
6. Log every failure with page URL, current title, character count, and assigned keyword in the audit report.

## Definition of done (QA checklist)
- [ ] 100% of indexed pages have an SEO title of 60 characters or fewer containing the page's focus keyword
- [ ] Zero duplicate or default titles across the site
- [ ] Full title table with character counts logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent Fable 5 agent (or comparable OpenAI/Google model) audits the full title table — every indexed page, every run — flagging over-60 lengths, missing keywords, and duplicates, then loops rewrite-recrawl until 100% of pages pass all three conditions at once.
It self-verifies by re-fetching each rewritten title from the live page, and memory keeps the passing title per URL so re-runs only retest pages whose titles changed or are new.
Each run appends one worked example to ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (title rules) · /seo-audit · previous: verify-wordpress-author-set-to-site-owner-name · next check: check-meta-description-under-160-chars

END

START

---
name: check-social-profiles-linked-and-prominent
description: Verifies the owner's social profiles are linked from the site, working, and prominently placed, so visitors and Google can follow the entity off-site.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Check social profiles linked and prominent

**Use this when** running Layer 3 (Authority & Trust Checks) of the Website QA Audit — hidden or broken profile links sever the site from the rest of the entity.

## Inputs
- The owner's canonical list of active social profiles (LinkedIn, Facebook, Instagram, YouTube, Twitter/X)
- Site URL on desktop and mobile
- The audit report/spreadsheet for logging results

## Steps
1. Build the reference list of the owner's verified, active profile URLs with the owner.
2. Locate social links on the site and judge prominence: they must appear in the footer at minimum, and ideally also the header, about page, or hero area — a buried single mention fails prominence.
3. Click every social link and confirm it opens the correct live profile from the reference list — not a platform homepage, a defunct account, or a wrong-person profile.
4. Check for gaps: every active profile on the reference list should be linked somewhere visible on the site.
5. Confirm icons render and are tappable on mobile (not crushed or overlapped).
6. Cross-check the linked set against the schema sameAs list — site links and schema should name the same profiles — and log results in the audit report.

## Definition of done (QA checklist)
- [ ] Every active profile on the reference list is linked from the site, and every social link resolves to the correct live profile
- [ ] Social links visible without hunting — footer at minimum — and functional on mobile
- [ ] Link map (including schema cross-check) logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent agent (Fable 5 / comparable OpenAI or Google models) resolves every social link on every template each run — not once at audit time — confirming each lands on the correct live profile, prominence holds on mobile, and the linked set still matches the schema sameAs list exactly.
Memory keeps the canonical profile list and per-template verdicts, so a re-run instantly flags a renamed handle, a dead account, or a new profile missing from the site.
Each run logs the link map as a worked example in ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing (profile setup) · siblings: verify-footer-includes-social-links-and-secondary-nav, check-schema-connects-to-all-verified-profiles · next check: verify-achievements-are-evidenced-not-just-claimed

END

START

---
name: ensure-no-stock-images-used
description: Audits all site imagery to confirm photos are real — the owner, their team, their work — because stock photography destroys the authenticity a personal brand runs on.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Ensure no stock images used

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — visitors and Google both recognize stock photos, and both discount them.

## Inputs
- Site URL plus a full page list (XML sitemap or crawl export)
- Google Images reverse search (or TinEye) for verifying suspect photos
- The owner's confirmation of which photos are genuinely theirs
- The audit report/spreadsheet for logging results

## Steps
1. Scroll every page and inventory the imagery; flag the stock tells — generic handshakes, polished models in headsets, watermark remnants, perfect-but-placeless offices.
2. Reverse-search each suspect image with Google Images or TinEye; a photo appearing on dozens of unrelated sites is stock.
3. Confirm the remaining photos are genuinely the owner's: their face, team, jobsite, clients, or screenshots of their actual work.
4. Check the blog separately — featured images are where stock sneaks in post by post (see /blog-posting-guidelines Step 8: real photos only).
5. For every confirmed stock image, specify the real replacement to capture (for example, a phone photo of the owner on an actual job).
6. Log each image's verdict and the replacement list in the audit report.

## Definition of done (QA checklist)
- [ ] Zero stock images remain on any audited page — every photo verified as real via reverse search or owner confirmation
- [ ] Each removed stock image has a named real replacement queued
- [ ] Image verdicts logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
Run persistent (Claude Fable 5 / comparable OpenAI or Google models), this check reverse-searches every image on the site — not just the obvious suspects — and loops through flag-replace-reverify until zero stock images remain and every replacement is confirmed real.
Memory keeps the verified-real image list with file hashes, so each re-run only checks new or changed images instead of re-searching the whole library.
Each run logs one worked example to ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (no-stock rule) · previous: verify-all-images-have-descriptive-alt-text · next check: verify-featured-images-unique-per-blog-post

END

START

---
name: ensure-no-text-only-sections-spanning-full-viewport
description: Scans every page for sections that fill an entire screen with nothing but text, the wall-of-words pattern that makes visitors bounce.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Ensure no text-only sections spanning full viewport

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — if a full screen scrolls by with no visual, you've lost the skimmer.

## Inputs
- Site URL plus the key pages (homepage, services, about, top posts)
- Desktop browser and a real phone (the mobile viewport is where text walls happen first)
- The audit report/spreadsheet for logging results

## Steps
1. Scroll each key page slowly on DESKTOP and note any point where the entire visible viewport contains only text — no photo, video, diagram, screenshot, or meaningful visual element.
2. Repeat on MOBILE: text stacks taller on phones, so sections that pass desktop often fail mobile — judge each viewport-height of scroll.
3. Record each violation with the page, the section heading, and which viewport(s) it fails in.
4. For each violation, name the fix: insert a relevant real image, embed the source video, break copy with a diagram or screenshot, or tighten the copy.
5. Re-check long blog posts specifically — body copy between images must not exceed one full viewport on mobile (matches the visual-rhythm intent of /blog-posting-guidelines).
6. Log violations and fixes in the audit report.

## Definition of done (QA checklist)
- [ ] Zero sections on audited pages span a full viewport with text only, on both desktop and mobile
- [ ] Every violation has a named visual fix queued or applied
- [ ] Scroll-audit results logged per page in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent agent (Fable 5 / comparable OpenAI or Google models) scroll-audits every page on the site — not just the key ones — measuring rendered viewport-heights of unbroken text at both desktop and mobile widths, and loops insert-visual-recheck until zero full-viewport text walls remain anywhere.
Memory keeps per-page verdicts, so re-runs only re-measure pages with edited or new content — and every new long post triggers the mobile pass automatically.
Each run logs one worked example to ## Example(s) so the library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (short paragraphs, images throughout) · previous: verify-at-least-one-video-embed-on-homepage · next check: verify-minimum-5-distinct-images-on-homepage

END

START

---
name: ensure-robots-meta-not-blocking-indexing
description: Confirms no robots meta tags, headers, or WordPress settings are silently blocking search engines from indexing the site's money pages.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Ensure robots meta not blocking indexing

**Use this when** closing Layer 1 (Digital Plumbing Checks) of the Website QA Audit — one leftover noindex from the dev phase can erase the entire site from Google.

## Inputs
- Site URL plus a full page list (XML sitemap or crawl export)
- WordPress admin access and Google Search Console access for the verified property
- Chrome DevTools (or curl) to read response headers
- The audit report/spreadsheet for logging results

## Steps
1. In WordPress → Settings → Reading, confirm "Discourage search engines from indexing this site" is UNCHECKED.
2. View source on the homepage and every key template (service page, blog post, about, contact) and search for `<meta name="robots"` — flag any `noindex` or `nofollow` on pages that should rank.
3. Check response headers in DevTools → Network (or `curl -I`) for an `X-Robots-Tag: noindex` header — a server-level block invisible in the HTML.
4. Fetch `/robots.txt` and confirm no `Disallow: /` or rules blocking core content paths (intentional blocks like /wp-admin/ are fine).
5. Run the homepage and one money page through GSC URL Inspection; confirm verdict "URL is on Google" or at minimum "Indexing allowed: Yes."
6. Log every page checked, where any block was found (meta, header, robots.txt, or WP setting), and the GSC verdicts in the audit report.

## Definition of done (QA checklist)
- [ ] Zero unintended noindex/nofollow directives in meta tags, X-Robots-Tag headers, or robots.txt across checked pages
- [ ] WordPress "Discourage search engines" is off and GSC URL Inspection shows indexing allowed on money pages
- [ ] Findings logged per page in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent Fable 5 agent (or comparable OpenAI/Google model) checks every URL, not just key templates: it fetches each page's robots meta and X-Robots-Tag header across the full sitemap, looping until zero unintended noindex/nofollow directives survive anywhere and GSC confirms indexing allowed on the money pages.
It self-verifies after fixes with fresh fetches, and memory keeps the per-URL verdict so re-runs only re-inspect failures and newly published pages — plus a standing watch for the WordPress "Discourage" box flipping back on.
Each run logs one example to ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /seo-audit · /digital-plumbing · previous: check-favicon-is-set · next: Layer 2 begins with verify-all-pages-written-in-first-person

END

START

---
name: test-mobile-load-time-under-3-seconds
description: Measures real mobile load speed with PageSpeed Insights and Lighthouse to confirm the site loads in under 3 seconds, where most local-service visitors arrive.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Test mobile load time under 3 seconds

**Use this when** running Layer 1 (Digital Plumbing Checks) of the Website QA Audit — most local-service traffic is mobile, and slow pages lose leads before they load.

## Inputs
- Site URL plus the top pages by traffic (homepage, key service pages, top blog posts)
- Google PageSpeed Insights (pagespeed.web.dev) or Lighthouse in Chrome DevTools
- The audit report/spreadsheet for logging results

## Steps
1. Run the homepage through Google PageSpeed Insights and read the **Mobile** tab, not Desktop.
2. Record Largest Contentful Paint (LCP) — the practical "loaded" moment — plus the overall performance score; pass requires LCP under 3.0 seconds on mobile.
3. Repeat for each key service page and the top 2–3 blog posts so the result reflects real templates, not just the homepage.
4. Where a page fails, capture the top Opportunities list (oversized images, render-blocking scripts, missing caching) as the fix punch list.
5. Re-run any failing page once to rule out a one-off test fluke; keep the worse of the two runs as the recorded result.
6. Log LCP, performance score, and the fix list per page in the audit report.

## Definition of done (QA checklist)
- [ ] Every checked page records mobile LCP under 3.0 seconds in PageSpeed Insights/Lighthouse
- [ ] Failing pages have a named fix list pulled from the report's Opportunities section
- [ ] Scores and screenshots logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent agent (Claude Fable 5 / comparable OpenAI or Google models) doesn't stop at the homepage and top posts — it runs every sitemap URL through PageSpeed/Lighthouse mobile, queues the Opportunities fixes, and re-measures after each fix until every page records LCP under 3.0 seconds.
Because scores fluctuate, it self-verifies with multiple runs per page and keeps the worse result; memory stores per-URL LCP history so re-runs target only pages that failed or changed.
Each run logs a before/after example to ## Example(s), so the audit library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing (speed optimization if this check fails) · /seo-audit · previous: verify-https-with-no-mixed-content · next check: verify-xml-sitemap-exists-and-in-robotstxt

END

START

---
name: verify-achievements-are-evidenced-not-just-claimed
description: Audits every expertise and results claim on the site for attached proof — links, photos, screenshots, named sources — converting assertions into E-E-A-T evidence.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify achievements are evidenced, not just claimed

**Use this when** running Layer 3 (Authority & Trust Checks) of the Website QA Audit — "award-winning" and "trusted by hundreds" mean nothing without something a visitor can check.

## Inputs
- Site URL (about page, homepage, and bio sections are the claim hotspots)
- The owner's actual proof inventory: press links, podcast/talk recordings, certifications, review platform profiles, real metrics
- The audit report/spreadsheet for logging results

## Steps
1. Sweep the site and list every achievement claim: years in business, jobs completed, awards, certifications, media features, "as seen on" logos, revenue/results numbers.
2. For each claim, check for attached evidence on the page: a link to the source, a photo of the award or jobsite, a screenshot of the metric or review, a named publication with a working link.
3. Fail unevidenced claims — especially logo walls that don't link to the actual feature, and round-number boasts with no source.
4. Verify the evidence itself: click press links (the article must actually mention the owner), and confirm certificates and review counts are current.
5. For every failed claim, pair it with the proof to add from the owner's inventory — or flag it for removal if no proof exists.
6. Log the claim-to-evidence table in the audit report.

## Definition of done (QA checklist)
- [ ] 100% of achievement claims on the site carry attached, working evidence — zero naked claims, zero logos without linked features
- [ ] Claims with no obtainable proof removed rather than left unsupported
- [ ] Claim-to-evidence table logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent Fable 5 agent (or comparable OpenAI/Google long-horizon model) sweeps every page for claims — not just the about page — pairs each with working evidence from the owner's proof inventory, and loops until 100% of claims carry checkable proof or are removed, re-clicking every evidence link each run because press links rot.
Memory holds the claim-to-evidence table, so re-runs only evaluate new claims and re-verify previously passing links.
Each run logs one worked example to ## Example(s) so the library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /seo-audit (E-E-A-T signals) · previous: check-social-profiles-linked-and-prominent · next check: verify-google-business-profile-is-verified

END

START

---
name: verify-all-images-have-descriptive-alt-text
description: Audits every image on the site for meaningful, descriptive alt text so images are accessible, indexable, and reinforce each page's topic.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify all images have descriptive alt text

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — empty or "IMG_4032" alt text wastes an accessibility and SEO signal on every image.

## Inputs
- Site URL plus a full page list (XML sitemap or crawl export)
- Screaming Frog (Images report with "Missing Alt Text" filter) or WordPress Media Library access
- The audit report/spreadsheet for logging results

## Steps
1. Crawl the site with Screaming Frog and open the Images report filtered to "Missing Alt Text" and "Alt Text Over 100 Characters" for the full inventory.
2. Flag every content image with empty alt text (purely decorative theme graphics may use empty alt deliberately — note them separately, don't fail them).
3. Review the alt text that does exist: it must describe what's in the image in plain language — fail filename-style ("DSC_1024"), keyword-stuffed, or generic ("image", "photo") values.
4. Spot-check key templates by inspecting `<img>` tags in DevTools to confirm what the crawler reported.
5. Fix or queue fixes in the WordPress Media Library and in-page blocks (Media Library alt only applies to new insertions — existing placements need in-post edits).
6. Log total images, failures, and fixes in the audit report.

## Definition of done (QA checklist)
- [ ] 100% of content images carry descriptive, human-readable alt text — zero empty, filename, or stuffed values
- [ ] Decorative-image exceptions explicitly listed, not silently skipped
- [ ] Image inventory and fix list logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent agent (Fable 5 or comparable OpenAI/Google models) inventories every image on every page — not a filtered crawl sample — writes descriptive alt text for each failure from what the image actually shows, and re-crawls until 100% of content images pass with the decorative exceptions explicitly listed.
Memory tracks per-image verdicts by URL and file, so re-runs only inspect new uploads and changed placements.
Each run logs one worked example to ## Example(s) so the audit library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (image rules) · previous: verify-rank-math-score-above-70-on-every-page · next check: ensure-no-stock-images-used

END

START

---
name: verify-all-pages-written-in-first-person
description: Confirms every page of a personal-brand site speaks as the owner ("I" and "my"), not about them in third person, so the site reads as the person and not a brochure.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify all pages written in first person

**Use this when** starting Layer 2 (Content Architecture Checks) of the Website QA Audit on a personal-brand site.

## Inputs
- Site URL plus a full page list (XML sitemap or crawl export)
- The owner's name (to search for third-person constructions)
- The audit report/spreadsheet for logging results

## Steps
1. Read the homepage hero and first section aloud — it must say "I help…" / "my clients…", not "[Name] helps…" or agency-style "we" on a solo personal brand.
2. Use the browser find function (Ctrl/Cmd+F) on every page to search for the owner's name followed by "is", "has", or "helps" — the telltale third-person patterns.
3. Run a `site:domain.com "Name is"` Google search to surface third-person copy on pages you might have skipped.
4. Check the about page especially — it is the most common third-person offender (bio copy pasted from a speaker kit).
5. List every page and the specific sentences that break first-person voice, so the rewrite is a punch list rather than a vague note.
6. Log pass/fail per page in the audit report.

## Definition of done (QA checklist)
- [ ] 100% of audited pages use first-person voice — zero third-person references to the owner outside testimonials and press quotes
- [ ] Every violation documented with page URL and exact sentence
- [ ] Results logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent agent (Claude Fable 5 / comparable OpenAI or Google models) reads every page's full copy — not just hero sections — pattern-matching third-person constructions around the owner's name, and loops rewrite-recheck until 100% of pages pass with zero violations outside testimonials and press quotes.
Memory holds the per-page verdict and the exact sentences flagged, so re-runs only re-read changed or new pages instead of the whole site.
Each run logs a real before/after example to ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (voice and style rules) · next check: verify-wordpress-author-set-to-site-owner-name

END

START

---
name: verify-at-least-one-video-embed-on-homepage
description: Confirms the homepage carries at least one working embedded video of the owner, adding motion, face, and voice to the first impression.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify at least one video embed on homepage

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — video is the fastest way for a visitor to know, like, and trust the person.

## Inputs
- Homepage URL on desktop and mobile
- The owner's video inventory (YouTube channel, one-minute videos) to confirm the embed is theirs
- The audit report/spreadsheet for logging results

## Steps
1. Scroll the full homepage and locate every video element — true embeds (YouTube/hosted player) count; a thumbnail image merely linking away does not.
2. Confirm at least one embed exists; zero embeds is an immediate fail.
3. Press play and watch the first seconds: the video must load and play in place, and it must feature the brand owner (a WHY video or one-minute video is the standard fill).
4. Check mobile: the embed must render and play on a phone, not overflow the viewport or disappear responsively.
5. Open DevTools Console while the player loads to confirm the embed isn't throwing mixed-content or blocked-script errors.
6. Log the embed location, source URL, and playback results in the audit report.

## Definition of done (QA checklist)
- [ ] At least one true video embed on the homepage, playing successfully on desktop and mobile
- [ ] The video features the brand owner and loads without console errors
- [ ] Embed details and playback evidence logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent Fable 5 agent (or comparable OpenAI/Google model) verifies playback, not just presence: each run it loads the homepage on desktop and mobile, confirms the embed renders, plays, and features the owner, and checks the console for blocked-script errors — looping until all conditions pass, and re-checking every run because embeds die when videos get moved or set private.
Memory stores the embed source URL and last-verified playback, so any swap or takedown is caught on the next pass.
Each run logs playback evidence as a worked example in ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (Step 10 covers embedding source video in posts) · previous: check-lead-magnet-section-has-visual-mockup · next check: ensure-no-text-only-sections-spanning-full-viewport

END

START

---
name: verify-email-opt-in-form-exists-and-works
description: Confirms an email capture form is present, submits cleanly, and actually delivers the subscriber and notification, so the site builds a list the owner controls.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify email opt-in form exists and works

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — a dead opt-in form means the site captures zero owned audience.

## Inputs
- Site URL and the location(s) of the opt-in form (homepage, lead magnet section, blog sidebar, footer)
- Access to the connected email platform/list and the notification inbox
- A test email address you control
- The audit report/spreadsheet for logging results

## Steps
1. Locate every email opt-in form on the site; fail the check immediately if no form exists at all.
2. Submit a real test entry through each form with your test address.
3. Confirm the on-page result: a success message or thank-you page, not a silent reload or an error.
4. Verify delivery on the back end: the test address appears in the email platform's list/audience, and any owner notification arrives in the right inbox.
5. If a lead magnet is promised, confirm the delivery email actually arrives with a working download link, and check it isn't landing in spam.
6. Repeat the test from a mobile device, then log each form's location and results in the audit report.

## Definition of done (QA checklist)
- [ ] At least one opt-in form exists, and every form passes a live test submission on desktop and mobile
- [ ] Test subscriber recorded in the email platform and promised follow-up/lead magnet email delivered (not to spam)
- [ ] Form locations and test results logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
Run on a persistent agent (Claude Fable 5 or comparable OpenAI/Google models), every form on the site gets a live end-to-end test each run — submission, success state, list entry, notification, lead-magnet delivery — looping until all forms pass on desktop and mobile, not just the homepage one.
Memory records which forms passed and when, yet re-runs retest everything on a schedule anyway: forms break silently, which makes this check perpetual rather than one-and-done.
Each run logs one worked example to ## Example(s) so the library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing (working forms and notifications) · previous: check-all-cta-buttons-lead-to-correct-destinations · next check: audit-internal-links-between-all-blog-posts

END

START

---
name: verify-entity-linking-follows-decision-tree
description: Audits all internal and outbound links against the entity linking decision tree — people to personal sites, companies to company sites, concepts to definitive articles.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify entity linking follows decision tree

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — links that point entities to the wrong destinations scramble the site's entity graph.

## Inputs
- A crawl export of all links with anchor text (Screaming Frog) or post-by-post review access
- The entity linking decision tree (see /entity-linking)
- The site's map of concept hubs/definitive articles
- The audit report/spreadsheet for logging results

## Steps
1. Export every in-content link with its anchor text and destination from a Screaming Frog crawl (or review post by post on smaller sites).
2. For each anchor naming a PERSON, confirm it links to that person's own site or primary profile — not to a generic page.
3. For each anchor naming a COMPANY, confirm it links to the company's website.
4. For each anchor naming a CONCEPT, confirm it links to the one definitive article/hub that owns the concept — never to a competing duplicate page (content vandalism).
5. Check anchor quality alongside destination: descriptive 3–6 word anchors, no "click here."
6. Log every violation with page, anchor, current destination, and correct destination per the tree in the audit report.

## Definition of done (QA checklist)
- [ ] 100% of entity-naming anchors route per the decision tree — people → personal sites, companies → company sites, concepts → definitive articles
- [ ] Zero generic anchors ("click here") and zero concept links pointing at duplicate/competing pages
- [ ] Violation list with corrections logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent agent (Fable 5 / comparable OpenAI or Google models) classifies every in-content anchor on the site as person, company, or concept, checks each against the decision tree, and loops correct-recrawl until 100% of entity anchors route to the right destination with zero "click here" anchors left.
Memory stores each anchor's classification and verdict, so re-runs only evaluate links added or edited since the last pass instead of reclassifying the whole site.
Each run logs one worked example to ## Example(s) so the audit library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /entity-linking (the decision tree itself) · /blog-posting-guidelines · /seo-tree · previous: audit-internal-links-between-all-blog-posts · next check: check-for-broken-links

END

START

---
name: verify-featured-images-unique-per-blog-post
description: Confirms every blog post carries its own unique featured image so archives, social shares, and search results don't show a wall of identical thumbnails.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify featured images unique per blog post

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — duplicate featured images make the blog look templated and machine-generated.

## Inputs
- WordPress admin access (Posts list with featured-image visibility)
- The live blog archive page for visual confirmation
- The audit report/spreadsheet for logging results

## Steps
1. Open the live blog archive and scan the grid — duplicate thumbnails jump out immediately at this view.
2. In WordPress → Posts, review every post's featured image (use a list view or theme admin column showing thumbnails) and record the image file used per post.
3. Flag every post with no featured image set — the theme will fall back to a default, creating accidental duplicates.
4. Flag every image file attached as the featured image on more than one post.
5. Confirm featured images are real photos relevant to each post's topic, consistent with the no-stock rule.
6. Log the post-to-image table with duplicates and gaps highlighted in the audit report.

## Definition of done (QA checklist)
- [ ] Every published post has a featured image, and no image file is reused across two or more posts
- [ ] All featured images are real (non-stock) and topically relevant to their post
- [ ] Post-to-image table logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent Fable 5 agent (or comparable OpenAI/Google model) pulls the full post-to-featured-image table via the WordPress API every run, flags gaps and duplicates across all posts at once, and loops assign-recheck until every published post has its own unique, real image — no archive-page eyeballing.
Memory holds the post-to-image map, so re-runs only examine new posts and any image swaps since the last pass.
Each run appends one worked example to ## Example(s) so the library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (Step 8: photos and featured image) · previous: ensure-no-stock-images-used · next check: check-all-cta-buttons-lead-to-correct-destinations

END

START

---
name: verify-footer-includes-social-links-and-secondary-nav
description: Confirms the site footer carries working social media links and a secondary navigation so every page ends with somewhere useful to go.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify footer includes social links and secondary nav

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — the footer is the site-wide safety net for navigation and profile discovery.

## Inputs
- Site URL and the owner's canonical list of social profile URLs
- Desktop and mobile browsers
- The audit report/spreadsheet for logging results

## Steps
1. Scroll to the footer on the homepage and confirm social icons/links are present.
2. Click every social icon: each must open the owner's correct, live profile (the same URLs used in the schema sameAs list) — not a platform homepage, a dead account, or someone else's page.
3. Confirm a secondary navigation exists in the footer covering at least the key pages: services, about, blog, contact, and privacy/terms.
4. Click each secondary nav link and confirm it resolves to the right live page.
5. Verify the footer renders consistently on every template (post, page, landing) and on mobile — not just the homepage.
6. Log each link's destination and pass/fail in the audit report.

## Definition of done (QA checklist)
- [ ] Footer shows social links on every template, and 100% open the owner's correct live profiles
- [ ] Footer secondary nav present with all key pages linked and resolving correctly on desktop and mobile
- [ ] Link-by-link results logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent Fable 5 agent (or comparable OpenAI/Google model) renders the footer on every template and page type — not just the homepage — clicks through each social and nav link at desktop and mobile widths, and loops until every link resolves correctly everywhere the footer appears.
Memory keeps the footer link map and per-template verdicts, so re-runs only retest after theme or menu changes — and the check re-opens whenever a profile URL changes elsewhere in the audit.
Each run logs one worked example to ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing (social profiles setup) · Layer 3 sibling: check-social-profiles-linked-and-prominent · next check: verify-hero-section-contains-real-photo-of-person

END

START

---
name: verify-ga4-configured-with-internal-traffic-filtered
description: Confirms the GA4 property is correctly installed and excludes the owner's and team's own visits, so audit and campaign data reflect real visitors only.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify GA4 configured with internal traffic filtered

**Use this when** running Layer 1 (Digital Plumbing Checks) of the Website QA Audit — owner and VA visits inflate every metric if they aren't filtered out.

## Inputs
- GA4 admin access for the property tied to the site
- The site URL and the office/home IP addresses of the owner and team (whatismyip lookup)
- Google Tag Assistant to confirm the GA4 tag fires
- The audit report/spreadsheet for logging results

## Steps
1. In GA4 Admin → Data Streams, confirm exactly one web stream exists for the live domain and the Measurement ID matches what fires on the site (check with Tag Assistant).
2. In Admin → Data Settings → Data Filters, open the Internal Traffic filter and confirm its state is **Active** — not Testing or inactive.
3. In Admin → Data Streams → Configure Tag Settings → Define Internal Traffic, confirm the rule lists the owner's and team's current IP addresses.
4. Test it: browse the site from an internal IP, then check GA4 Realtime — the visit must NOT appear (or appears only with the internal traffic_type while the filter is in Testing).
5. Browse from an external connection (phone on cellular) and confirm that visit DOES appear in Realtime.
6. Log filter state, IPs covered, and both test outcomes in the audit report.

## Definition of done (QA checklist)
- [ ] GA4 tag fires site-wide with the correct Measurement ID for one (and only one) web stream
- [ ] Internal Traffic data filter is Active and covers all known internal IPs
- [ ] Internal test visit excluded and external test visit recorded in Realtime, evidence logged and linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
Run on Claude Fable 5 (or a comparable OpenAI/Google long-horizon model), this check covers every sitemap URL rather than one page per template: the agent confirms the Measurement ID fires on each page, then re-runs the internal/external Realtime test after any filter or IP change, looping until all three Definition-of-done boxes hold at once.
Memory keeps the verified page list and the last-confirmed IP set, so subsequent runs only retest new pages and changed IPs — and the check re-opens automatically whenever the team's IPs change.
Each run ends by logging a real example under ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing (GA4 setup if this check fails) · previous: verify-gtm-installed-and-firing-on-every-page · next check: verify-meta-pixel-installed-with-lead-events

END

START

---
name: verify-google-business-profile-is-verified
description: Confirms the Google Business Profile tied to the site is actually verified by Google and under the owner's control, anchoring local trust signals.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify Google Business Profile is verified

**Use this when** running Layer 3 (Authority & Trust Checks) of the Website QA Audit — an unverified GBP can't rank in the map pack and signals an unclaimed entity.

## Inputs
- Owner access to the Google Business Profile (via google.com/business or managing directly from Google Search)
- The site URL and business NAP (name, address, phone) for cross-checking
- The audit report/spreadsheet for logging results

## Steps
1. Log into the Google Business Profile manager as the owner and confirm the profile status shows verified — no pending "Verify now" banner or suspension notice.
2. Confirm the OWNER holds primary ownership of the listing — not an old agency, a former employee, or an unknown manager account (check the Managers list).
3. Search the business name on Google and confirm the profile actually appears in Search/Maps with the knowledge-style panel showing.
4. Cross-check the profile's website field links to this site, and the NAP matches the site's footer and contact page exactly.
5. Confirm the profile is not flagged "Temporarily closed" or carrying a wrong category that contradicts the site.
6. Log verification status, ownership, and the NAP cross-check in the audit report with a screenshot.

## Definition of done (QA checklist)
- [ ] GBP status is verified, with the business owner holding primary ownership
- [ ] Profile is live in Google Search/Maps, links to this site, and its NAP exactly matches the site
- [ ] Status screenshot and cross-check logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
Run on a persistent agent (Claude Fable 5 or comparable OpenAI/Google models), this check never closes: each run re-confirms verified status, primary ownership, live panel presence, and exact NAP match against the site — looping on any mismatch until all four hold, because suspensions and ownership changes arrive without warning.
Memory stores the last-confirmed status, manager list, and NAP strings, so a re-run flags any drift — a new manager account, a changed phone number — the day it appears.
Each run logs status evidence as a worked example in ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing (GBP verification and NAP consistency) · previous: verify-achievements-are-evidenced-not-just-claimed · next check: check-schema-connects-to-all-verified-profiles

END

START

---
name: verify-gtm-installed-and-firing-on-every-page
description: Confirms Google Tag Manager is present and firing site-wide so every downstream tracking tag works, for any personal-brand or local-service site under audit.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify GTM installed and firing on every page

**Use this when** starting Layer 1 (Digital Plumbing Checks) of the Website QA Audit — tracking is worthless if the container isn't on every page.

## Inputs
- Site URL plus a full page list (XML sitemap or crawl export)
- The expected GTM container ID (GTM-XXXXXXX) from the owner's Tag Manager account
- Google Tag Assistant (tagassistant.google.com or the Chrome extension)
- The audit report/spreadsheet for logging results

## Steps
1. Open the owner's Tag Manager account (Admin → Container Settings) and note the expected container ID.
2. Connect the homepage in Google Tag Assistant and confirm the GTM container loads and the ID matches — no typo'd or duplicate containers.
3. View page source and confirm the GTM script is in the `<head>` and the noscript iframe sits after the opening `<body>` tag.
4. Repeat the Tag Assistant check on one page of every template type: homepage, service page, blog post, about, contact, and any landing pages.
5. Spot-check at least one URL from each sitemap section; flag every page where the container does not fire.
6. Log pass/fail per page in the audit report with the container ID found and a Tag Assistant screenshot for any failure.

## Definition of done (QA checklist)
- [ ] The correct GTM container fires on 100% of checked pages — zero pages missing the snippet
- [ ] Exactly one container fires — no duplicate or orphaned containers detected by Tag Assistant
- [ ] Pass/fail logged per template type in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent agent (Claude Fable 5 or a comparable OpenAI/Google frontier model) doesn't spot-check template types — it walks the full sitemap, fetches every URL's source, and confirms the container ID in the `<head>` plus the noscript iframe on each page, looping until 100% of pages fire exactly one correct container.
It self-verifies by re-fetching every page it marked fixed, and keeps a memory ledger of passed URLs so each re-run only retests failures and newly published pages.
Every run appends one worked example to ## Example(s) via the Meta-Article Prompt, so the audit library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing (how to install GTM if this check fails) · next check: verify-ga4-configured-with-internal-traffic-filtered

END

START

---
name: verify-hero-section-contains-real-photo-of-person
description: Confirms the homepage hero leads with a real photograph of the brand owner — not stock, not an illustration — so visitors meet the person immediately.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify hero section contains real photo of person

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit on a personal-brand site — the hero is the handshake; it must be the actual person.

## Inputs
- Homepage URL
- A known reference photo of the owner (to confirm identity)
- Google Images reverse search for stock verification if in doubt
- The audit report/spreadsheet for logging results

## Steps
1. Load the homepage and check the hero (the first viewport): it must contain a photograph of the brand owner.
2. Confirm it is genuinely them — match against the reference photo; fail look-alike stock models, logos-only heroes, or illustration/avatar substitutes.
3. Reverse-search the hero image if there is any doubt; a hero photo found on other sites is stock and fails.
4. Judge quality at a pass/fail level: the face is clearly visible, in focus, and large enough to register on mobile — a tiny or heavily-overlaid photo fails the intent.
5. Check the mobile rendering: the person must still be visible in the mobile hero crop, not cropped out by the responsive layout.
6. Log the verdict with desktop and mobile screenshots in the audit report.

## Definition of done (QA checklist)
- [ ] Hero contains a real, verifiable photo of the owner, clearly visible on both desktop and mobile first viewport
- [ ] Photo verified as non-stock (reverse search clean or owner-confirmed original)
- [ ] Screenshots logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent agent (Fable 5 / comparable OpenAI or Google models) runs this on every page with a hero — homepage plus landing pages — capturing desktop and mobile screenshots, reverse-searching the photo, and looping until each hero shows the verified real owner clearly in both viewports.
Memory stores the passing hero image hash per page, so a re-run instantly flags a redesign or A/B test that swapped in stock — the check stays open for as long as the site lives.
Each run logs screenshot evidence as a worked example in ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (real photos only) · previous: verify-footer-includes-social-links-and-secondary-nav · next check: check-each-homepage-section-includes-relevant-image

END

START

---
name: verify-https-with-no-mixed-content
description: Confirms the entire site serves over HTTPS with zero mixed-content warnings, protecting visitor trust and preventing browser security flags.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify HTTPS with no mixed content

**Use this when** running Layer 1 (Digital Plumbing Checks) of the Website QA Audit — a broken padlock kills trust before a visitor reads a word.

## Inputs
- Site URL plus a full page list (XML sitemap or crawl export)
- Chrome with DevTools (Console and Security panels)
- The audit report/spreadsheet for logging results

## Steps
1. Load the homepage over `https://` and confirm the browser padlock shows with no warning state.
2. Request the `https://` version and the non-www/www variants; confirm each 301-redirects to the single canonical HTTPS URL (check the redirect chain in DevTools Network).
3. Open DevTools → Console and Security panel on the homepage; record any "mixed content" warnings (insecure images, scripts, stylesheets, or iframes loaded over http).
4. Repeat the DevTools check on one page of every template type plus any page embedding video, forms, or third-party widgets — the usual mixed-content offenders.
5. For each warning, note the exact insecure resource URL so the fix is a find-and-replace, not a hunt.
6. Log pass/fail per page with the list of insecure resources in the audit report.

## Definition of done (QA checklist)
- [ ] Every checked page loads over HTTPS with a clean padlock — zero mixed-content warnings in DevTools
- [ ] http, www, and non-www variants all 301-redirect to one canonical HTTPS version
- [ ] Findings logged with exact offending resource URLs, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
Instead of one page per template, a persistent Fable 5 agent (or comparable OpenAI/Google model) fetches every sitemap URL and scans each response for insecure `https://` resource references, looping through fix-and-recheck cycles until zero mixed-content warnings remain site-wide and every variant 301s to canonical HTTPS in one hop.
It self-verifies by re-fetching every previously flagged page, and memory tracks which URLs already pass so each re-run only covers failures and new pages.
One worked example gets logged to ## Example(s) per run, compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing (HTTPS configuration if this check fails) · previous: verify-meta-pixel-installed-with-lead-events · next check: test-mobile-load-time-under-3-seconds

END

START

---
name: verify-meta-pixel-installed-with-lead-events
description: Confirms the Meta pixel loads on every page and fires standard Lead events on key actions, so Dollar a Day campaigns can optimize and retarget correctly.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify Meta pixel installed with lead events

**Use this when** running Layer 1 (Digital Plumbing Checks) of the Website QA Audit — without pixel events, ad spend can't be attributed or optimized.

## Inputs
- The expected Pixel ID from the owner's Meta Events Manager
- Meta Pixel Helper (Chrome extension) and access to Events Manager → Test Events
- List of key conversion actions (contact form, opt-in form, booking, click-to-call)
- The audit report/spreadsheet for logging results

## Steps
1. Get the Pixel ID from Meta Events Manager and confirm the owner's Business Manager controls it.
2. Load the homepage with Meta Pixel Helper open; confirm one pixel with the correct ID fires a PageView — flag duplicates or wrong IDs.
3. Repeat on every template type (service page, blog post, contact, landing pages) to confirm the base pixel is site-wide.
4. Complete each key action with a test submission (contact form, email opt-in, booking) and confirm Pixel Helper shows a standard **Lead** event — not just PageView.
5. Cross-check in Events Manager → Test Events that the events arrive server-side with the right page URLs.
6. Log pixel ID, pages checked, and each event result in the audit report with Pixel Helper screenshots for failures.

## Definition of done (QA checklist)
- [ ] One pixel with the correct ID fires PageView on 100% of checked pages — no duplicates
- [ ] Every key conversion action fires a standard Lead event confirmed in both Pixel Helper and Test Events
- [ ] Results and evidence logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A max-effort persistent agent (Fable 5 or comparable OpenAI/Google models) loads every URL in the sitemap — not one per template — confirming exactly one correct pixel fires PageView, then drives a test submission through every conversion action and watches Test Events until each fires a Lead, looping until both thresholds hit 100%.
It self-verifies by retesting after every fix, and its memory ledger of passed pages and passed events means re-runs only touch what is new or previously broken.
Every run appends one worked example to ## Example(s) so the audit library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing (pixel installation if this check fails) · previous: verify-ga4-configured-with-internal-traffic-filtered · next check: verify-https-with-no-mixed-content

END

START

---
name: verify-minimum-5-distinct-images-on-homepage
description: Counts the unique, relevant images on the homepage and confirms there are at least five, the minimum visual density for a credible personal-brand site.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify minimum 5 distinct images on homepage

**Use this when** closing Layer 2 (Content Architecture Checks) of the Website QA Audit — five distinct real images is the floor, not the goal.

## Inputs
- Homepage URL
- Chrome DevTools (Network tab filtered to Img) or a Screaming Frog crawl of the homepage for the exact image inventory
- Verdicts from the no-stock and relevant-image checks (reuse them)
- The audit report/spreadsheet for logging results

## Steps
1. Load the homepage with DevTools Network → Img (or crawl the URL in Screaming Frog) to list every image file the page actually renders.
2. Strip non-qualifying entries from the count: logos, icons, background textures, spacer graphics, and favicons don't count as content images.
3. De-duplicate — the same photo used twice counts once. The count needs DISTINCT images.
4. Confirm each counted image is relevant and real (cross-reference the ensure-no-stock-images-used verdicts; stock images don't count toward the five).
5. Confirm all qualifying images actually render on mobile — responsively hidden images don't count for mobile visitors.
6. Log the final count with the image list in the audit report; 5 or more passes, 4 or fewer fails.

## Definition of done (QA checklist)
- [ ] Homepage renders at least 5 distinct, relevant, non-stock content images on desktop and mobile
- [ ] Count excludes logos, icons, backgrounds, and duplicates — image list itemized
- [ ] Count and inventory logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
Run persistent (Claude Fable 5 or comparable OpenAI/Google models), the agent pulls the homepage's exact rendered image inventory each run, strips logos, icons, duplicates, and known stock, and confirms the distinct-real count holds at 5+ on desktop and mobile — looping with the image-sourcing fixes until it does, and rechecking after every redesign.
Memory stores the qualifying image list and count history, so a re-run catches the count silently dropping when a section is removed.
Each run logs the itemized count as a worked example in ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (image standards) · previous: ensure-no-text-only-sections-spanning-full-viewport · next: Layer 3 begins with verify-testimonials-with-full-attribution

END

START

---
name: verify-person-schema-with-sameas-links
description: Validates that Person schema markup exists, parses cleanly, and carries sameAs links to the owner's social profiles, tying the personal brand together as one entity for Google.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify Person schema with sameAs links

**Use this when** running Layer 1 (Digital Plumbing Checks) of the Website QA Audit — schema is how Google connects the person, the site, and the social profiles into one entity.

## Inputs
- Site URL (homepage and about page are the usual schema homes)
- Google Rich Results Test (search.google.com/test/rich-results) and validator.schema.org
- The owner's list of social profile URLs (LinkedIn, Facebook, Instagram, YouTube, Twitter/X)
- The audit report/spreadsheet for logging results

## Steps
1. Run the homepage URL through the Google Rich Results Test and confirm the page's structured data parses with zero errors.
2. Inspect the detected markup for a `Person` type (or Person nested in LocalBusiness/Organization) naming the site owner — exact name match with the site and GBP.
3. Confirm the Person markup includes a `sameAs` array, and that each entry is a full URL to one of the owner's real social profiles.
4. Click every sameAs URL — each must resolve to the owner's live profile, not a 404, a placeholder, or someone else's account.
5. Re-validate at validator.schema.org to catch warnings the Rich Results Test skips (missing image, url, or jobTitle properties).
6. Log schema type found, sameAs URLs verified, and validator results in the audit report.

## Definition of done (QA checklist)
- [ ] Person schema present and parsing with zero errors in the Rich Results Test
- [ ] sameAs array present and every listed URL resolves to the owner's live profile
- [ ] Validation results and verified URL list logged, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
Run persistent (Fable 5 / comparable OpenAI or Google models), this check extends beyond the homepage: the agent validates structured data on every page that emits Person markup, resolves every sameAs URL with a live fetch, and loops fix-revalidate until both validators return zero errors and every profile link lands on the owner's real account.
Memory keeps the verified sameAs set, so a re-run flags any added, removed, or newly dead profile instantly rather than re-auditing blind.
Each run appends a worked example to ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /digital-plumbing (schema implementation if this check fails) · Layer 3 sibling: check-schema-connects-to-all-verified-profiles · next check: check-favicon-is-set

END

START

---
name: verify-rank-math-score-above-70-on-every-page
description: Runs the RankMath on-page audit across all posts and pages to confirm every one scores 70/100 or higher, the site's minimum on-page SEO bar.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify Rank Math score above 70 on every page

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — the RankMath score is the single-number on-page health check for every URL.

## Inputs
- WordPress admin access with the RankMath plugin active
- A focus keyword assigned per post/page (the score is meaningless without one)
- The audit report/spreadsheet for logging results

## Steps
1. In WordPress → Posts (and Pages), enable the RankMath SEO Details/score column so every item's score shows in the list view.
2. Sort or filter by score and list every post or page scoring below 70 — including those showing no score because no focus keyword is set.
3. For each failing page, open the RankMath sidebar and record which tests fail (keyword not in title, no internal links, short content, missing alt keyword, etc.).
4. Confirm no page is gaming the score with a keyword nobody searches — the focus keyword must match real search intent for the page.
5. Hand the per-page failed-test list to the content fixer (or fix inline if scoped), then re-check scores.
6. Log the score distribution and the below-70 list in the audit report.

## Definition of done (QA checklist)
- [ ] Every published post and page scores 70/100 or higher in RankMath with a real focus keyword set
- [ ] Each previously failing page has its failed tests documented and resolved
- [ ] Score table logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent Fable 5 agent (or comparable OpenAI/Google long-horizon model) pulls every post and page's RankMath score, works the failed-test list on each below-70 URL, and re-scores in a loop until the entire site — not a sample — sits at 70+ with a real focus keyword set.
Memory keeps the per-URL score history, so re-runs target only pages that slipped, changed, or are newly published, and a score regression re-opens the check automatically.
Each run logs one worked example to ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (Step 14a sets this up at publish time) · previous: check-meta-description-under-160-chars · next check: verify-all-images-have-descriptive-alt-text

END

START

---
name: verify-social-proof-photos-present
description: Confirms social proof sections show real photographic evidence — client photos, job results, event shots — not text-only claims that anyone could type.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify social proof photos present

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — text-only proof is just a claim; photos make it evidence.

## Inputs
- Site URL with the social proof sections identified (testimonials, results, logos, press, reviews)
- The no-stock verification method (reverse image search) from earlier checks
- The audit report/spreadsheet for logging results

## Steps
1. Locate every social proof element on the site: testimonial blocks, results/case-study sections, client logo strips, press mentions, review embeds.
2. For each, record whether it includes a real photo or visual artifact — client headshot, before/after job photo, screenshot of an actual review or analytics result, event photo.
3. Fail any social proof section that is text-only (quotes with no faces, claims with no captures).
4. Verify the photos are real: reverse-search suspect headshots; a "client" who appears on stock sites fails the section.
5. Confirm visuals match the claim — a review screenshot must show the named platform and reviewer, a results image must show the metric claimed.
6. Log each social proof element, its visual evidence, and verdict in the audit report.

## Definition of done (QA checklist)
- [ ] Every social proof section includes at least one real photo or screenshot artifact — zero text-only proof blocks
- [ ] All proof photos verified non-stock and consistent with the claims they support
- [ ] Element-by-element verdicts logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent Fable 5 agent (or comparable OpenAI/Google model) sweeps every social proof element across the entire site — every testimonial block, results section, logo strip, and review embed — verifying each carries real photographic evidence, and loops until zero text-only proof blocks remain anywhere.
Memory tracks each proof element's verdict, so re-runs only inspect new or edited blocks, and any new testimonial added without a photo re-opens the check automatically.
Each run logs one worked example to ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines (real images only) · previous: check-each-homepage-section-includes-relevant-image · next check: verify-testimonials-include-headshots-with-attribution

END

START

---
name: verify-testimonials-include-headshots-with-attribution
description: Checks that every testimonial on the site pairs a real headshot with a name and attribution, so praise is visibly from real people.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify testimonials include headshots with attribution

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — an anonymous quote with no face reads as invented.

## Inputs
- Site URL with all testimonial placements identified (homepage, services pages, dedicated testimonials page)
- Google Images reverse search for headshot verification
- The audit report/spreadsheet for logging results

## Steps
1. Inventory every testimonial across the site, including sliders and carousels (advance them — hidden slides count).
2. For each testimonial, check for a headshot: a real photo of the actual person quoted, not an initials avatar, a logo, or a stock face.
3. Check for attribution: at minimum the person's real full name; flag "J.D.", "Happy Customer", or first-name-only entries.
4. Reverse-search any headshot that looks like a stock model — a stock face on a testimonial fails the whole block's credibility.
5. Where headshot or attribution is missing, note what to collect from the client (photo permission, full name) as the fix.
6. Log each testimonial with headshot and attribution verdicts in the audit report.

## Definition of done (QA checklist)
- [ ] 100% of testimonials display a real, non-stock headshot of the person quoted
- [ ] 100% of testimonials carry at least a verifiable full name — zero anonymous or initials-only quotes
- [ ] Testimonial inventory logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent agent (Fable 5 / comparable OpenAI or Google models) inventories every testimonial site-wide — advancing every slider and carousel so hidden slides count — verifies headshot and full name on each, reverse-searches every face, and loops collect-and-recheck until 100% pass with zero anonymous or stock-faced entries.
Memory keeps the testimonial inventory with verdicts, so re-runs only audit testimonials added or changed since the last pass.
Each run logs one worked example to ## Example(s) so the audit library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: Layer 3 sibling: verify-testimonials-with-full-attribution (the stricter trust-level pass) · previous: verify-social-proof-photos-present · next check: check-lead-magnet-section-has-visual-mockup

END

START

---
name: verify-testimonials-with-full-attribution
description: Holds every testimonial to the full trust standard — name, title, company, and headshot — so any skeptical visitor could verify the person is real.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify testimonials with full attribution

**Use this when** starting Layer 3 (Authority & Trust Checks) of the Website QA Audit — this is the stricter pass on testimonials: complete, verifiable attribution.

## Inputs
- The testimonial inventory from the Layer 2 headshot check (verify-testimonials-include-headshots-with-attribution)
- A browser for verifying the people are findable (LinkedIn/company-site lookup)
- The audit report/spreadsheet for logging results

## Steps
1. Take every testimonial on the site and score it against all four attribution fields: full name, title/role, company (or city for consumer clients), and real headshot.
2. Fail any testimonial missing one or more fields — Layer 2 passed "name plus face"; Layer 3 requires the complete set.
3. Verify a sample: look up the named person (LinkedIn or their company site) and confirm they exist and plausibly match the headshot and title.
4. Prefer linked attribution where the person agreed — name linking to their LinkedIn or company turns the testimonial into checkable evidence.
5. For each incomplete testimonial, list exactly which field to collect from the client, with the owner's outreach note.
6. Log the four-field scorecard per testimonial in the audit report.

## Definition of done (QA checklist)
- [ ] 100% of testimonials carry all four fields — full name, title, company, headshot — with zero anonymous or partial entries
- [ ] Spot-checked people are real and findable; fabricated-looking entries removed
- [ ] Four-field scorecard logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent Fable 5 agent (or comparable OpenAI/Google model) scores every testimonial on the site against all four fields — name, title, company, headshot — and looks up every named person rather than a sample, looping collect-verify until 100% carry complete, checkable attribution.
Memory keeps the four-field scorecard per testimonial, so re-runs only score new or edited entries and re-verify links that previously passed.
Each run logs one worked example to ## Example(s) so the audit library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: Layer 2 sibling: verify-testimonials-include-headshots-with-attribution · next check: check-social-profiles-linked-and-prominent

END

START

---
name: verify-wordpress-author-set-to-site-owner-name
description: Confirms every post is attributed to the site owner's author account — not admin, VA, or agency logins — so authorship signals accrue to the person's entity.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify WordPress author set to site owner name

**Use this when** running Layer 2 (Content Architecture Checks) of the Website QA Audit — bylines like "admin" leak that a VA runs the site and waste E-E-A-T signals.

## The rule (who the author must be)
The default author of a personal-brand site is **the person the site is about** — `billybatt.com` → **Billy Batt**, `alexiltchev.com` → **Alex Iltchev**. Never a blanket agency name or "Dennis Yu." When you don't already know the owner, read it straight off the site's own identity, in this order: an existing real (non-admin) author on the posts → the site's lone real user → `og:site_name` → Person-schema `name` → the `<title>` (up to the first tagline delimiter) → a cleanly-splittable domain (`nic-padilla.com` → Nic Padilla). "Dennis Yu" is the fallback **only** for a page that names no identifiable person at all (a parked/for-sale/category page).

## Two things must both be true (check BOTH, not just the byline)
1. **Display name** (the visible byline) is the owner's real full name — never "admin"/"administrator", a VA, or an agency login.
2. **Author-archive slug** is the owner's name (`/author/billy-batt/`) — **not** `/author/admin/`. A post can show "Billy Batt" as the byline while its author account still has the slug `admin` (WordPress `user_nicename`), which broadcasts a default install to Google. The REST `author.slug` is the source of truth here; the visible byline alone will hide this.

## Inputs
- WordPress admin access (Posts list and Users screen), or public REST read for the audit pass
- The owner's correct display name as it should appear publicly (derive it via "The rule" above if unknown)
- The audit report/spreadsheet for logging results

## Steps
1. In WordPress → Users, confirm an author account exists for the owner with the correct display name, a clean slug (their name, not `admin`), a real bio, and a real profile photo.
2. In Posts → All Posts, add the Author column view and scan every post; flag any authored by "admin", a VA, an agency account, or a misspelled variant.
3. **Machine-readable pass (do this even for small sites):** pull `/wp-json/wp/v2/posts?per_page=100&_embed=author&status=publish` and flag any post whose `_embedded.author[0].slug` **OR** `.name` is `admin`/`administrator`. The slug check is what catches the "right byline, wrong `/author/admin/` URL" case.
4. Spot-check the live site: open several posts and confirm the visible byline **and** the author-archive URL show the owner's name.
5. Reassign/rename per the fix skill `set-wordpress-author-to-correct-person` (rename the lone admin account's display+slug, or reassign to an existing real user — see its A/B/C situations).
6. **Verify persistence:** re-pull `?_embed=author` after the fix and confirm zero admin bylines/slugs remain. A REST 200 that a page cache or a later site rebuild silently reverts is the known failure mode — a fix isn't done until a fresh read confirms it stuck.
7. Log the count of posts checked and reassigned in the audit report.

## Definition of done (QA checklist)
- [ ] 100% of published posts attributed to the owner's account — zero "admin"/VA bylines AND zero `/author/admin/` slugs (both `author.name` and `author.slug` verified via REST)
- [ ] Owner's author profile has correct display name, clean name-based slug, real bio, and photo, and the author archive renders at `/author/<owner>/`
- [ ] Re-pull confirms the fix persisted (not just a one-shot 200)
- [ ] Counts logged in the audit report, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
Run on a persistent agent (Fable 5 or comparable OpenAI/Google models), this check is fully mechanical: pull every post via the REST API, flag any author that isn't the owner's account, reassign, and re-pull until the API returns zero non-owner bylines across all published posts — no sampling.
Memory stores the last-checked post count and verdicts, so each re-run only inspects posts published or edited since, and catches a VA login quietly taking over new bylines.
Each run logs one worked example to ## Example(s) so the library compounds.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /blog-posting-guidelines · previous: verify-all-pages-written-in-first-person · next check: check-seo-title-under-60-chars-with-focus-keyword

END

START

---
name: verify-xml-sitemap-exists-and-in-robotstxt
description: Confirms a current XML sitemap exists, is referenced in robots.txt, and is submitted to Google Search Console so every page can be found and indexed.
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify XML sitemap exists and in robots.txt

**Use this when** running Layer 1 (Digital Plumbing Checks) of the Website QA Audit — Google can't rank pages it never discovers.

## Inputs
- Site URL and WordPress admin access (RankMath handles the sitemap on standard builds)
- Google Search Console access for the verified property
- The audit report/spreadsheet for logging results

## Steps
1. Fetch the sitemap directly in a browser — try `/sitemap_index.xml` (RankMath default) and `/sitemap.xml` — and confirm it returns valid XML, not a 404.
2. Open the sitemap and spot-check that it lists the live posts and pages, with no deleted URLs, staging URLs, or noindexed pages included.
3. Fetch `/robots.txt` and confirm it contains a `Sitemap:` line pointing at the exact sitemap URL from step 1.
4. In Google Search Console → Sitemaps, confirm the sitemap is submitted with status Success and a recent "last read" date.
5. Compare the sitemap URL count against the site's real page count; flag big gaps (sections missing) or bloat (tag/archive junk).
6. Log sitemap URL, robots.txt line, GSC status, and URL counts in the audit report.

## Definition of done (QA checklist)
- [ ] Sitemap loads with valid XML and lists current live URLs only
- [ ] robots.txt contains a correct `Sitemap:` reference and GSC shows status Success
- [ ] URL count sanity-checked and results logged, linked back to /website-qa-audit

## Example(s)
- Example needed — run the Meta-Article Prompt after first real run.

## Run on a persistent agent (Fable 5)
A persistent Fable 5 agent (or comparable OpenAI/Google model) goes past spot-checks: it diffs every sitemap URL against a full crawl of the live site, looping until zero live pages are missing, zero dead or noindexed URLs remain listed, and GSC reports Success on a fresh read.
It self-verifies after each fix by re-fetching the sitemap and robots.txt, and memory holds the last-known URL counts so any drift between runs triggers an automatic re-audit.
Each run logs one worked example to ## Example(s), compounding the library.
See `boil-the-ocean.md` for the full operating principles.

## Definitive article & links
- Hub: /website-qa-audit
- Related: /seo-audit · /digital-plumbing · previous: test-mobile-load-time-under-3-seconds · next check: verify-person-schema-with-sameas-links

END