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.

Le fichier de compétence

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

## Ce qu’il vous faut d’abord

- 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éthode

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.

## Ce que ça produit

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.

## Là où ça dérape

- 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

---

Extrait de la bibliothèque de compétences QuQi - https://www.quqi.io/fr/skills/template-level-onpage-audit

Ce qu’il vous faut d’abord

• 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éthode

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.

Ce que ça produit

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.

Là où ça dérape

• 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

Utiliser cette compétence dans votre propre IA

Le fichier téléchargé est un simple markdown dont l'en-tête porte le nom et le déclencheur. Quand un assistant sait charger des compétences tout seul, c'est cet en-tête qu'il lit pour décider que celle-ci s'applique.

Plus dans SEO on-page