Template-Level On-Page Audit
On a generated site most on-page problems are not page problems. A missing H1, a duplicated title pattern or a description built from the first twenty words is emitted by a component, so a page-level audit produces 800 spreadsheet rows describing six bugs. Crawling everything and exporting issues buries that structure and sends content people work they cannot do. Group faults by the template that produced them before anyone writes a ticket.
FORMAT
template-level-onpage-audit.md
WHEN TO REACH FOR THIS
Use when the same on-page fault appears across hundreds of pages and a page-by-page fix list will never be finished.
The skill file
template-level-onpage-audit.md
---
name: template-level-onpage-audit
description: Use when the same on-page fault appears across hundreds of pages and a page-by-page fix list will never be finished.
---
# Template-Level On-Page Audit
On a generated site most on-page problems are not page problems. A missing H1, a duplicated title pattern or a description built from the first twenty words is emitted by a component, so a page-level audit produces 800 spreadsheet rows describing six bugs. Crawling everything and exporting issues buries that structure and sends content people work they cannot do. Group faults by the template that produced them before anyone writes a ticket.
## What you need first
- A crawl of rendered HTML exporting title, meta description, every H1, canonical and word count per URL
- A map of URL patterns to templates or page types, taken from the CMS or the router rather than guessed
- Access to the template source, not only its output
## Method
1. Classify every crawled URL into a page type by URL pattern before looking at any field. Templates, not topics, are the unit of this audit.
2. Within each type, count distinct title patterns after stripping the variable parts. One pattern across 400 URLs is a template decision; forty patterns means authored titles and belongs in a different workflow.
3. Sample five URLs per type at random and read them fully. Aggregate exports hide the faults that only appear when a field is empty, such as a title collapsing to the bare site name.
4. Test the edge cases deliberately: the product with no description, the category with one item, the author with no bio. Templates fail at their edges, and those are usually the thin pages.
5. Trace each fault to the component that emits it and record the fix once per component with the number of URLs it clears. That count is what gets the work scheduled.
6. Separate faults that are pure template logic from faults that need per-page content written. Only the first kind can ship this week, and it should ship first.
7. Recrawl the affected patterns after deploy and confirm the affected count is zero. A template fix either works everywhere or is not fixed.
## What this produces
A per-template fault list naming the emitting component, the fix and the URLs it clears, typically under a dozen rows for a site of thousands of pages.
## Where this goes wrong
- Handing a per-URL issue export to writers when most rows share one cause that no writer can reach
- Sampling only well-populated pages, so the empty-state failures that create the thin pages are never seen
- Fixing the template against synthetic staging content, then finding real content overflows the field
- Bundling a template logic fix and a copy rewrite into one release, so neither effect can be attributed
---
From the QuQi skill library - https://www.quqi.io/skills/template-level-onpage-audit
Free to download · no account, no email
What you need first
-
A crawl of rendered HTML exporting title, meta description, every H1, canonical and word count per URL
-
A map of URL patterns to templates or page types, taken from the CMS or the router rather than guessed
-
Access to the template source, not only its output
Method
-
01
Classify every crawled URL into a page type by URL pattern before looking at any field. Templates, not topics, are the unit of this audit.
-
02
Within each type, count distinct title patterns after stripping the variable parts. One pattern across 400 URLs is a template decision; forty patterns means authored titles and belongs in a different workflow.
-
03
Sample five URLs per type at random and read them fully. Aggregate exports hide the faults that only appear when a field is empty, such as a title collapsing to the bare site name.
-
04
Test the edge cases deliberately: the product with no description, the category with one item, the author with no bio. Templates fail at their edges, and those are usually the thin pages.
-
05
Trace each fault to the component that emits it and record the fix once per component with the number of URLs it clears. That count is what gets the work scheduled.
-
06
Separate faults that are pure template logic from faults that need per-page content written. Only the first kind can ship this week, and it should ship first.
-
07
Recrawl the affected patterns after deploy and confirm the affected count is zero. A template fix either works everywhere or is not fixed.
What this produces
A per-template fault list naming the emitting component, the fix and the URLs it clears, typically under a dozen rows for a site of thousands of pages.
Where this goes wrong
-
Handing a per-URL issue export to writers when most rows share one cause that no writer can reach
-
Sampling only well-populated pages, so the empty-state failures that create the thin pages are never seen
-
Fixing the template against synthetic staging content, then finding real content overflows the field
-
Bundling a template logic fix and a copy rewrite into one release, so neither effect can be attributed
Use this skill in your own AI
The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.
Claude Code
Save it as ~/.claude/skills/template-level-onpage-audit/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude
Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT
There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else
Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.
Questions about this skill
When do I audit by template rather than crawl and export the issues?
When the same fault appears across hundreds of URLs. The obvious move is to crawl everything and hand the issue export to the content team, which produces 800 rows describing six bugs and sends writers work they cannot do. On a generated site the fault belongs to a component, so the audit unit is the template, not the page.
What do I need in hand before starting?
A crawl of rendered HTML with title, description, every H1, canonical and word count, a URL-pattern to template map taken from the CMS or router rather than guessed, and access to the template source. Guess the map and you will group pages by topic, which cuts across templates and produces fault groups nobody can assign to an owner.
What do I end up with, and which part gets used?
A fault list keyed to templates, naming the emitting component, the fix and the URL count it clears, typically under a dozen rows for a site of thousands of pages. The count is the part that gets used: it is what gets the work scheduled, because one ticket clearing 4,000 URLs is priced differently from one clearing nine.
What most often ruins this?
Sampling only the well-populated pages. Templates fail at their edges, so the product with no description and the category with one item are where the thin pages come from, and those are exactly the URLs a comfortable sample misses. The related cost is testing the fix against staging content, then watching real strings overflow the field in production.
More in On-page SEO