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.

O ficheiro da competência

---
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.

## O que precisa primeiro

- 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

## Método

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.

## O que isto produz

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.

## Onde isto corre mal

- 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

---

Da biblioteca de competências da QuQi - https://www.quqi.io/pt/skills/template-level-onpage-audit

O que precisa primeiro

• 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

Método

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 07 Recrawl the affected patterns after deploy and confirm the affected count is zero. A template fix either works everywhere or is not fixed.

O que isto produz

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.

Onde isto corre mal

• 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 esta skill na sua própria IA

O ficheiro é markdown simples, com o nome e o gatilho no frontmatter. Quando um assistente consegue carregar skills sozinho, é esse frontmatter que lê para decidir que esta se aplica.

Mais em SEO on-page