Missing browser or PageSpeed quota: continue with explicit limits

Playwright is one browser option, not a global audit gate. Test whichever browser capability the agent actually has; if none can access authenticated tools, request GSC/GA4 CSV exports through F-FILE and continue public crawl, source, sitemap, and supplied-file analysis. Record browser-only/rendered checks as unavailable until evidence arrives. Do not infer a rendering pass from raw HTML. Tool unavailability is a limitation of this audit environment, not evidence that the client’s website is broken.

For PageSpeed HTTP 429, record the response and URL/strategy, check for an already configured PAGESPEED_API_KEY or GOOGLE_API_KEY without displaying either value. Prefer the dedicated PageSpeed key; if absent or unusable, try the existing Google key once. Pass the selected value as the API key and verify the response: its environment-variable name does not guarantee that PageSpeed is enabled, permitted by key restrictions, or within quota. Redact keys from commands, URLs, logs, and saved evidence. Do not repeatedly call the same anonymous endpoint. A new key is optional and does not guarantee quota. Try a human-supplied PageSpeed report or local Lighthouse when Chrome and the runtime are available; neither requires Playwright. Keep Lighthouse lab measurements separate from field Core Web Vitals. If no route is available, record Performance as not measured and continue the audit. Ask once for the missing evidence; do not wait indefinitely or create cloud accounts during the audit.

A report may be delivered with these explicitly documented evidence gaps once the applicable analysis and claim-check QA are complete. Mark affected collection rows unavailable with their reason and collection action; do not mark them passed. With missing performance or other category evidence, show measured categories but withhold the overall 0–100 Health Score until its inputs exist. Do not substitute zero, invent a score, or silently redistribute weights. This evidence-gap rule takes precedence over instructions elsewhere to display a total score or wait for every collection row.

Sources: PageSpeed API setup and Lighthouse execution options.

Phase 1: Data Collection Checklist

Collect all of this before invoking any skills. The more complete the data, the more specific the skill outputs.

Site Profile and conditional router

Inspect the live site and available repository/deployment context first. Record approximate URL count, CMS/framework/hosting, static/SSR/CSR/hybrid rendering, access/deployment route, markets/languages, ecommerce/local/publisher/image/video/internal-search features, log access, and available tools.

Use the profile to activate relevant modules. CSR/hybrid/unknown activates expanded response-vs-rendered checks; structured data activates Search Appearance outcome tracking; public internal search activates its bounded check; large templated sites activate template/root-cause sampling. Record a reasoned N/A for anything skipped. Start change-events.md for dated deployments, migrations, template/plugin releases, content/analytics changes, and external incidents.

Google Search Console

  • Safety first — record Manual Actions and Security Issues as clear, affected, or inaccessible. An affected result is authoritative Google evidence and a blocker before ordinary optimization.
  • Freshness next — capture Performance → 24 hours with hourly clicks/impressions, compare with the previous 24 hours where possible, and check Google’s Search Status Dashboard plus Search Console data anomalies. Label it preliminary; it can trigger investigation but cannot prove cause or justify a rollback by itself.
  • Performance export — 12 months, all queries, all pages, all countries. Export both the queries table and the pages table as CSV.
  • Indexing exports — three separate exports:
    • “Not indexed” → filter by “Crawled — currently not indexed” → export URL list
    • “Not indexed” → filter by “Discovered — currently not indexed” → export URL list
    • “Not indexed” → filter by “Duplicate, Google chose different canonical than user” → export URL list
    • “Pages with issues” → 404 / not found → export URL list
  • Core Web Vitals — screenshot of the CWV field data report for mobile and desktop

GA4

  • Property name check (do this first): confirm the property name matches the site you expect to be tracking.
  • Landing pages report — date range matching your GSC export, all landing pages, with as many conversion events as you have configured.
  • Channel data quality check: if Direct channel has more than 3× the sessions of Organic Search and engagement rate below 25%, flag it before using in analysis.

PageSpeed Insights

  • Run on homepage (mobile). Note: Performance score, LCP, TBT, FCP, CLS.
  • If time allows: run on top 3-5 landing pages by organic traffic.
  • Network dependency tree: scan for CDN or font domains that don’t match the production domain.

Manual page and share-preview checks

For the homepage, top commercial page, top organic landing page, pricing page, and one article, capture the H1, title, meta description, schema types, and page type. Also check og:title, og:description, and og:image; confirm the image is a resolvable absolute HTTPS URL and the fields describe the current page rather than a stale template. Open one representative share preview where practical.

Open Graph affects how links appear when shared on social and messaging platforms. Treat it as an easy share-preview and click-through check, not a Google ranking factor.

Response vs rendered HTML — conditional expansion

On one representative page, compare the HTTP response/page source with the rendered DOM for final URL, title, meta description, canonical, robots, H1, primary content, crawlable links, and JSON-LD. If the site is CSR/hybrid/unknown or material differences appear, expand to up to three templates. Corroborate one material difference with URL Inspection’s Google view or the Rich Results Test; browser rendering alone is not proof of what Google processed. A static/SSR site may mark the expanded module N/A only after a representative comparison shows no material dependency.

Conditional CMS/framework adapter

When source or CMS access exists and the audit produces an implementable recommendation, create a version-aware implementation adapter. It maps each shared root cause to the client’s real configuration, layout, component, template, or CMS field; cites current primary documentation; and defines affected/unaffected regression tests, rollback, production build, deploy, and live verification. If there is no implementation access or action, mark it N/A instead of generating generic platform advice.

The first adapter supports Astro. It checks the installed version, astro.config.*, route generation, shared head/layout fields, sitemap membership and truthful source-backed <lastmod>, hosting configuration, generated HTML, and the live deployment. A successful build is recorded separately from deployed and live verification.

Structured-data outcome loop

Validate representative page types with both Rich Results Test and Schema.org Validator. Also capture the applicable GSC Enhancement report and Performance → Search appearance baseline: appearance type, valid/invalid where reported, impressions, clicks, CTR, date range, and examples. After an approved schema change, revalidate live immediately and compare the same appearance type at 2/4/8 weeks. Keep valid, eligible, and shown separate; valid markup never guarantees display.

Evidence-based content refresh / merge / prune

Build a canonical URL register with comparable finalized GSC periods, GA4 conversions, backlink/referral evidence, substantive update date, user/business/support value, overlap/successor, current SERP/query evidence, and technical state. Age, word count, low traffic, or a >30% loss only trigger review.

Diagnose demand, seasonality, content/competitive loss, SERP/CTR change, technical/indexing, tracking, or volatility before choosing Protect/Refresh/Merge/Differentiate/Redirect/Noindex/Remove/Investigate. Destructive actions are Red: require explicit approval after checking links, conversions, obligations, replacement quality, recovery limits, and redirect/canonical/sitemap changes. Never “refresh” by changing the date alone.

Crawl Stats and server logs — conditional

Capture the 90-day GSC Crawl Stats baseline. Below roughly 1,000 URLs with healthy crawling and no direct constraint, server-log analysis is normally N/A. Request bounded logs only for a large/rapidly changing site, material discovered backlog, facet/parameter space, migration, host/5xx/429 trouble, or important-page recrawl lag. Define the question, period, fields, and privacy handling first, then verify real Google crawler requests through DNS or published IP ranges. Crawl-volume movement by itself is not a crawl-budget diagnosis.

Export GSC’s sampled linked pages, linking sites, linking text, and internal links with date and limits. Add Ahrefs/Bing when available but keep provider indexes separate. Use the baseline to protect valuable links, reclaim useful broken targets, and identify verified outreach opportunities.

Never automatically recommend or create a disavow file. Google says most sites do not need it and misuse can harm performance. It is Red and only considered for a considerable artificial-link pattern plus a related Manual Action or credible link-scheme risk, after expert review and removal attempts.

Internal site search — conditional

If the site has public internal search, open one normal result URL and one result URL containing the harmless URL-encoded marker <b>audit-search-check</b>. Record status, canonical, meta robots / X-Robots-Tag, sitemap and internal-link exposure, plus how the query appears in source and the rendered title, H1, and body.

  • No search: mark N/A.
  • Crawlable noindex and escaped text: pass or low observation.
  • Indexable results with escaped text: Medium; recommend noindex, sitemap removal, and controlled crawl paths.
  • Markup interpreted as HTML: High; route to a developer/security review and call it unsafe reflected-input handling—not confirmed XSS.

This is a harmless SEO check, not a penetration test: do not use script or exploit payloads. Keep a noindex URL crawlable so Google can see the directive. Save the evidence for the generated action runbook, which must separate the indexability fix from any unsafe-input review.

Squirrel Scan — MANDATORY

Do not skip. Without Squirrel Scan data, skill outputs are generic.

🔒 Security note: Squirrel Scan may trigger a Windows Defender or SmartScreen warning because it crawls websites over the network. This is expected behavior for a web auditing tool — it reads your website's HTML and checks 230+ SEO rules, similar to how a browser works. You can verify it at the official Squirrel Scan repository.

Run the crawl:

squirrel audit https://[client-domain] --max-pages <page-limit> --coverage full --format llm --output squirrel-report.txt

Replace <page-limit> with a numeric limit chosen from the sitemap URL count and expected crawl scope, leaving room for redirects and non-sitemap URLs. Discovered URLs can exceed sitemap counts; there is no universal safe multiplier. If the crawl reports that it capped, or reaches the configured limit without confirming completion, increase the limit and re-run. If scope or resources require stopping, label it a partial crawl. Record sitemap count, discovered/audited counts, limit, exclusions, and completion status alongside the output. Do not present a capped score as a full-site score or compare scores from different crawl scopes without explaining the difference.

What it gives you that nothing else does:

  • The actual URLs of every page Google crawled but rejected
  • Every broken external link by URL
  • Every internal nofollow link (page builders misconfigure these constantly)
  • JSON-LD validation errors per URL with the specific field that’s wrong
  • Missing or misconfigured security headers
  • Credential or API key leaks in HTML source
  • Accessibility errors at scale with the specific elements failing
  • Scores across 18 categories that ground every recommendation in a rule ID

SERP captures (with page-type classification)

Freeze 5–10 validated commercial query clusters with locale, device, collection method, client landing URL, confirmed competitors, and the page-type taxonomy. Run the same panel each cycle.

  • Screenshot the full SERP including AI Overview, PAA boxes, featured snippet, and organic results.
  • Classify every top-10 result by page type: product, comparison, alternatives-list, blog-post, glossary, tool/calculator, landing-page, docs, forum-thread, video, aggregator.
  • Identify the dominant page-type pattern. If 7+/10 results share a type, that’s what Google has decided the query rewards.
  • Flag page-type mismatches. If the client ranks with a page that isn’t the dominant type, that’s an SXO finding.
  • On later cycles record entrants/exits, page-type consensus, feature owners, client landing-URL switches, and confirmed competitor movement. Inspect live pages before attributing a cause; ranking or <lastmod> movement alone does not prove strategy.

AI-search opportunity and citation sample

Reuse the persona and validated keyword seeds already collected—do not add another onboarding questionnaire. Build a stable 20–50 prompt sample across the funnel and record the platform/surface, date, locale, exact context and prompt, observable web-search behaviour, exposed search queries, brand mentions, client citations, and cited domains. Generated prompts are hypotheses rather than demand data; validate content actions independently and consolidate related questions instead of creating one page per prompt.

Save the observations and fixed benchmark so the action runbook can rerun the same sample monthly. If AI-assisted discovery is genuinely irrelevant, record the reason and skip it rather than inventing a GEO section.

robots.txt + sitemap

  • https://[domain]/robots.txt — paste contents into a text file
  • https://[domain]/sitemap_index.xml — note structure and any missing sitemap types