--- name: seo-audit-evidence-checker description: Check a small site's important URLs against their live response, page identity, canonical, internal links and downloadable files; produce an evidence-backed issue list, not an invented SEO score. license: CC-BY-4.0 --- # SEO audit evidence checker Use this when someone asks whether a sitemap and its key pages actually work. This skill checks the difference between a URL returning HTTP 200 and serving the intended page. It is a read-only audit; it never changes a site, submits a sitemap, or promises ranking gains. ## Ask for only these inputs 1. A public site URL, or a local build directory. If both are given, compare both and label them separately. 2. A sitemap URL or explicit list of important URLs. If neither exists, ask for one or build a small list from a public homepage and label it as a sample, never a full-site audit. 3. Optional: known download links, expected content types, and the owner's intended canonical domain. Do not ask for Search Console credentials. If the user later supplies Search Console exports, treat them as separate indexing evidence, not live-response evidence. Never log a private token in output. ## Workflow ### 1. Freeze a reproducible sample Record audit time, site hostname, sitemap URL and total URL count. If more than 100 pages, check every URL's response and metadata when tooling allows; otherwise sample by page family and say how many of how many. Keep the first five examples for each issue, not a wall of duplicate rows. Avoid claiming a full crawl when the request times out. ### 2. Test the response, not just status For each URL, capture final URL after redirects, HTTP status, content type, page title, H1, meta robots, and canonical. Normalize URL fragments away but do not silently treat distinct query pages as identical. Fetch the homepage and one deliberately nonexistent path as controls. Hash the main HTML after removing only known volatile analytics scripts or timestamps; a sitemap URL with the homepage title/canonical/body is a soft-404 candidate even if its HTTP status is 200. A missing URL should return a real 404 or 410 with a useful not-found page and no indexable sitemap entry. ### 3. Check page identity and relationships For intended indexable pages, confirm that the page identity matches its URL, the canonical points to that same final page or a clearly intended parent, and the sitemap doesn't list unrelated homepage copies. Follow at least one internal navigation link from nested pages using the browser's normal URL resolution rules: relative `href="insights/"` on a nested path points to the wrong place; root-relative `/insights/` does not. Treat redirects and intentional canonical clusters as a judgment call, not an automatic error. For each advertised download, verify bytes and content type: a `.csv` must parse as a rectangular CSV with a header and at least one data row; a `.md` must be text and contain the described instructions. A 200 response containing homepage HTML is a broken download. ### 4. Write evidence-backed findings Output a table with `URL | expected | observed status/final URL | title/canonical or file type | verdict | recommended fix`. Verdicts: `pass`, `soft-404 candidate`, `broken download`, `bad internal link`, `canonical mismatch`, `unverified`. Prioritize fixes that affect a whole template or sitemap family. Give exact counts checked and affected, plus five representative URLs. A true 404 needs to be tested again after deployment; creating a `404.html` file locally is only a staged fix. Do not assert that a page is indexed because it is in a sitemap, or that an HTTP 200 means the file is valid. Do not invent monthly search volumes, traffic forecasts, structured-data eligibility, or Search Console results. Only mention those if independently observed from their own sources. Do not copy site content into a public report if it contains private data; use URL and narrow technical evidence. ### 5. Handoff If you can edit the site, propose a minimal diff and verify current build/source before writing. After deployment, re-fetch the changed URLs, a random missing path and at least two unaffected pages; visually inspect the changed not-found or landing page. If not authorized to deploy, stop at the report and mark all fixes `proposed`, never `live`. ## Fictional sample Input sitemap: `https://demo.example/sitemap.xml` lists `/`, `/guides/seo-check/` and `/templates/audit/audit.csv` is linked from a page. The `/guides/seo-check/` response is 200 but has title `Demo Home` and canonical `https://demo.example/`; the CSV URL responds 200 `text/html` and begins ``. Expected findings: | URL | Observed | Verdict | Fix | | --- | --- | --- | --- | | `https://demo.example/guides/seo-check/` | 200, homepage title and canonical | soft-404 candidate | Restore the distinct guide or return 404 and remove the sitemap URL. | | `https://demo.example/templates/audit/audit.csv` | 200, HTML instead of CSV | broken download | Publish a parseable CSV and test its response bytes. | Do not call the sample pages indexed, or claim the recommended fixes were deployed.