Advanced full SEO audit skill. Runs its own full workflow from local scripts, including the basic SEO checks plus PageSpeed, social metadata, and advanced review modules when available.

seo audit full — Advanced Full SEO Audit This skill runs a full single page SEO audit from the seo audit full directory. It does not route to seo audit when only a URL is provided. When to Use This Skill Use seo audit full when the user asks for: "seo audit full" "full SEO audit" "advanced SEO audit" "technical SEO audit" "deep audit" "comprehensive SEO review" "audit everything" URL only requests are valid. When external datasets are not supplied, run the full public signal workflow and clearly note missing data sources in the report. Input Expected Input Required Notes Page URL Yes The primary page to audit Primary keyword Recommended Improves content relevance scoring PageSpeed API key Yes Required for full audit PageSpeed checks. Ask at the start and do not run PageSpeed without it. Raw HTML or page content Optional Enables more accurate content checks when supplied GSC / crawl / analytics data Optional Include when supplied, otherwise mark unavailable Competitor benchmark data Optional Include when supplied At the start of a full audit, ask the user for a PageSpeed Insights API key: Do not run seo audit full PageSpeed checks without a PageSpeed API key supplied by api key , PAGESPEED API KEY , or GOOGLE PAGESPEED API KEY . If the key is missing, stop and ask the user to configure it instead of rendering a full report with missing PageSpeed data. Architecture: Full = Core + Performance + Advanced Output Produce an Advanced Full SEO Audit Report by filling the template at [assets/report template.html](assets/report template.html), then save it to a file — never print raw HTML to the terminal . File naming: reports/<hostname <slug full audit.html After saving, tell the user: If yes → run: open reports/example com full audit.html Template placeholders — fill each independently: Placeholder Content {{summary verdict}} One sentence: total checks run, how many failed/warned/passed {{summary critical html}} <li per critical item, or <li class="summary empty" None</li {{summary warnings html}} <li per warning item, or <li class="summary empty" None</li {{summary passing html}} <li per passing check, or <li class="summary empty" None</li {{pagespeed checks html}} Full PageSpeed module using check pagespeed.py output {{site checks html}} Site level check tables {{eeat checks html}} E E A T trust page table {{page checks html}} Page level check tables, including full only additions {{priority actions html}} Ordered priority action list {{insights html}} Optional finding walkthrough cards Scripts Run full scripts from this directory. All output is structured JSON — use it directly as evidence. Dependencies: pip install requests Phase 1: Core scripts Phase 2: Full only scripts Each script exits with code 0 (all pass/warn) or 1 (any fail/error). PageSpeed can take 200 seconds. Use a 180 second timeout by default. If it still times out, mark the Page Speed module as error and state that the PageSpeed API timed out; do not treat that as confirmed page performance failure. If PageSpeed fails because Google returns a quota/API key error after a key was provided, keep the audit running and render the PageSpeed module as error with this instruction: Get a PageSpeed API key at https://developers.google.com/speed/docs/insights/v5/get started → "Acquiring and using an API key" → "Get a Key". Scope — Full Audit Check Whitelist Full runs its own core checks plus the full only items marked ★ below. Site Level Checks (in {{site checks html}} ) Core checks: Sitemap URL Inventory · Staging Subdomain Indexation · robots.txt · sitemap.xml · 404 Handling · URL Canonicalization · i18n / hreflang Staging Subdomain Indexation rules: Check common staging/test hosts before robots.txt: test. , staging. , dev. , preview. , beta. , uat. Fail when a staging/test subdomain is publicly accessible, closely mirrors the production site, and is not protected by authentication, noindex , or a blocking robots.txt . Warn when a staging/test subdomain is publicly accessible but similarity or index protection cannot be confirmed. Pass when no public staging/test subdomain is detected, or detected staging hosts are protected by authentication, non 200 access, noindex , or Disallow: / . Explain the impact as duplicate indexable pages: Google may treat test.example.com and www.example.com as separate but near identical URLs, splitting ranking signals and competing with the production site. Recommended fixes: add Basic Auth/password protection first; also block crawlers on the staging host with User agent: + Disallow: / ; add page level noindex if pages can still be accessed. Sitemap URL Inventory rules: Place this as the first module in {{site checks html}} , before the Crawlability table. Render it as its own table with columns: Directory · URL Count · Page Type · Example Page. Use check site.py sitemap inventory output to summarize first level directories, URL counts, inferred page types, and one representative example URL. Treat this as a site level map, not a pass/fail single page SEO audit. Use status info unless sitemap URLs cannot be parsed; do not penalize a site for having many or few URLs in a directory without deeper evidence. Always include a next step note: the user can continue with deeper full audits by selecting representative sample URLs from major directories such as /blog/ , /tools/ , /alternatives/ , /templates/ , or /use cases/ . Page Speed Checks (in {{pagespeed checks html}} ) Full only: Lighthouse category scores: Performance · Accessibility · Best Practices · SEO Lab metrics: FCP · LCP · TBT · CLS · Speed Index Final URL and screenshot availability E E A T Checks (in {{eeat checks html}} ) Core checks: About Us · Contact · Privacy Policy · Terms of Service · Media/Partners (only if present) Contact logic (Contact row only): A dedicated /contact page is not required Pass if contact is reachable via any of: dedicated contact page (HTTP 200) · About page with contact details · footer/nav mailto, email, social links, or contact form Fail only when no contact pathway exists anywhere on the site Missing /contact alone is not a fail when About or footer/nav already expose contact info E E A T infrastructure rules — two layers per trust page: Layer 1 — Exists: HTTP 200 for the trust page URL (Contact uses Contact specific rules above) Layer 2 — Reachable: linked from footer or main nav Page Required About Us Yes Contact Yes — dedicated page optional; About or footer/nav contact details satisfy this Privacy Policy Yes Terms of Service Yes Media / Partners No — include only if present Status rules (About, Privacy, Terms, Media/Partners): Page missing (non 200) → Fail Page exists but not linked in footer/nav → Warn Page exists and linked in footer/nav → Pass Optional page missing → skip, do not include row Contact specific rules: 1. Try common paths ( /contact , /contact us ) — HTTP 200 counts as Exists 2. If no contact page, check the About page body for email, social, or contact details 3. Also scan homepage footer and nav for mailto: , visible email, social links, or a contact form 4. Exists Pass if any contact pathway is found 5. Exists Fail only when no contact information is found anywhere 6. Reachable Pass if a contact page link or contact details appear in footer/nav 7. Reachable Warn if contact is only reachable inside About page content, not directly in footer/nav 8. Do not recommend creating /contact when About or footer already expose contact info Page Level Checks (in {{page checks html}} ), output in this exact order: Core checks: URL Slug · Title Tag · Meta Description · H1 Tag · Canonical Tag · Image Alt Text · Word Count · Keyword Placement · Heading Structure · Internal Links · Schema (JSON LD) Schema (JSON LD) rules: Treat Schema as a quality check, not only a presence check. Validate JSON LD parseability, expected @type , required fields, recommended rich result fields, nested fields, and primary type conflicts. Fail when JSON LD is invalid, the expected schema type is missing, required fields are missing, or localized schema clearly points to the wrong language/URL. Warn when recommended fields are missing, nested fields are incomplete, multilingual pages lack inLanguage , or localized schema cannot be fully confirmed. Pass only when the expected schema type is present, required fields are present, no conflicts are found, and localized schema matches the current page language/URL when applicable. For multilingual pages, each language version should have its own schema with matching inLanguage , language specific headline/description where present, and url / mainEntityOfPage pointing to the current localized canonical URL. ★ Full only additions: OG Tags — og:title, og:description, og:image, og:type, og:url presence and validity Twitter Card — twitter:card type, title/description/image (with OG fallback detection) How to Use Script JSON Output Same rules across full audit modules — map each field's status directly to the report check table: status → pass / warn / fail / error → badge in report detail → starting point for Evidence line Do not contradict script output unless you have additional observable evidence For check site.py output: staging subdomains.status → Staging Subdomain Indexation row status staging subdomains.detail → Staging Subdomain Indexation row detail staging subdomains.public hosts → evidence for public staging/test hosts staging subdomains.similar hosts → fail evidence for production like staging duplicates robots.status → robots.txt row status sitemap.status → sitemap.xml row status sitemap inventory.status → Sitemap URL Inventory module status sitemap inventory.directories[] → table rows with path , url count , page type , and example url sitemap inventory.detail → short explanatory note below the inventory table For check schema.py output: status → Schema (JSON LD) row status detail → Schema (JSON LD) row detail parse errors → fail evidence for malformed JSON LD schemas[].fields missing → fail evidence for missing required schema fields schemas[].recommended missing and schemas[].nested issues → warning evidence localized schema.status → language/URL alignment status for multilingual schema localized schema.issues → evidence for schema language or URL mismatch For check social.py output: og.status → OG Tags row status twitter card.status → Twitter Card row status og.fields. → individual field details for the detail cell twitter card.fields. → individual field details, note fallback fields For check pagespeed.py output: status → overall Page Speed status category status → Lighthouse Scores badge status metric status → Core Lab Metrics badge status final url → Final URL line categories.performance.score → Performance score categories.accessibility.score → Accessibility score categories["best practices"].score → Best Practices score categories.seo.score → SEO score compact metrics.fcp.display value → FCP compact metrics.lcp.display value → LCP compact metrics.tbt.display value → TBT compact metrics.cls.display value → CLS compact metrics.si.display value → Speed Index screenshot truthy → Screenshot available Do not use overall status for the Lighthouse Scores badge. Category scores use Lighthouse thresholds: 90–100 pass, 50–89 warn, 0–49 fail. Example: Performan

seo-audit-full