Content template exception log
A practical record for changing an article template when its normal structure gets in the way of the reader's task.
content template exception log
A content template exception log records why an article needs a different structure from the site's normal pattern. The entry should connect the change to a reader need, show what will replace the standard section, and keep the decision available for editing and release review.
Templates save time when they carry useful defaults. They become awkward when an editor keeps an irrelevant section only because the field exists, or stretches a narrow answer until it fills a shape designed for another kind of page.
Open an exception before the draft depends on it. Record the route or brief, template version, requested change, requester, accountable editor, decision date, affected components, and the revision that contains the accepted structure.
Name the reader problem
Describe what the normal template would make harder for the reader. A comparison may need criteria beside each option rather than one long section per product. A short policy update may need a dated change record and the governing text, while a process guide may need steps, prerequisites, and failure paths.
Point to evidence in the brief, review notes, support records, or search result sample. Do not approve an exception because a writer wants variety or dislikes a heading. Taste can inform the design, but the record needs a practical reason another editor can inspect.
State the page promise before choosing the replacement. Google Search Central asks whether content helps its intended audience achieve a goal and provides a satisfying experience. That test is more useful than measuring whether every article has identical section names.
Describe the smallest useful exception
List the exact template rule that changes. The request might remove an irrelevant comparison table, change the order of two sections, use a decision tree instead of a linear procedure, or add a correction notice near the affected claim. Avoid phrases such as use a custom layout because they leave the actual boundary undefined.
Then name what replaces the default. If a standard benefits section is removed from a troubleshooting article, the replacement could be a symptom and resolution table that supports the reader's immediate task. If nothing replaces the section, explain why the page is complete without it.
Keep the exception narrow. A different section order does not grant permission to change the canonical route, byline, source rules, or release roster. Separate any additional request so its evidence and approver are visible.
Protect the rules that do not move
An exception may change presentation or sequence, but it should not lower the article's evidence standard. Claims still need support at their actual scope, and uncertainty still belongs in the copy. A novel layout cannot turn a nearby source into proof for a broader statement.
Keep metadata, accessibility, media rights, internal link governance, schema accuracy, indexing, sitemap ownership, originality, and repository checks in their normal release path. Record any component that needs a different test because the structure changed, such as keyboard behavior for an interactive decision aid.
Preserve the reader-visible byline and truthful dates. Do not use a template exception to add a fictional expert, hide a material correction, or refresh the displayed date without a material review.
Review the exception in context
Ask a reviewer to inspect the brief and the proposed structure together. The reviewer should be able to identify the reader task, find the missing or harmful default, understand the replacement, and distinguish the exception from the rules that still apply.
Use a small content sample when the layout is difficult to judge in the abstract. A representative heading, paragraph, table row, and mobile view can reveal whether the replacement is clearer or merely different. Keep private customer or product material out of a sample that will enter the repository.
Approve, revise, or reject the request with a short reason. Name any conditions that must be true before drafting continues, and require a fresh review when later scope changes reach beyond the accepted boundary.
Verify the rendered page
A source file can make the exception look tidy while the rendered page tells another story. Inspect the canonical route at the supported desktop and mobile widths. Check heading order, reading sequence, keyboard access, link context, media alternatives, tables, callouts, and any navigation generated from section data.
Compare the page with the accepted exception entry. Confirm that the removed default did not return through a shared component and that the replacement appears once in the intended position. Inspect Article metadata and any other machine output the route produces.
Run the ordinary content and repository gates as well as the test added for the exception. Save the immutable reviewed revision, then verify the same structure on the live route after deployment rather than treating a preview or deployment start as publication proof.
Use repeated exceptions to repair the template
Review the log on a regular editorial cadence. Group entries by template rule, reader task, content type, component, and outcome. Repeated exceptions can show that a default is too broad, its instruction is unclear, or the site now publishes a page type the template never covered.
Do not turn one unusual article into a new universal rule. Compare several accepted cases, the reviewer reasoning, rendered results, and maintenance cost before changing the base template. Preserve dissent or mixed outcomes instead of counting only the exceptions that looked successful.
When the template changes, name the version and effective date, update its tests and examples, and close the affected exception entries. Keep the old rationale so future editors can tell whether a difference is deliberate, inherited, or new drift.
Sources
- Creating helpful, reliable, people-first content, Google Search Central. Supports evaluating whether content serves its intended audience, helps readers achieve their goal, and provides a satisfying experience.
Related GTM guides
Frequently asked questions
What belongs in a content template exception log?
Record the affected route or brief, template version, reader problem, exact rule being changed, replacement structure, owner, reviewer, decision, conditions, and reviewed revision. Link the reason to evidence another editor can inspect.
Which rules should a template exception never weaken?
Keep the normal standards for evidence, metadata, accessibility, media rights, governed links, schema, indexing, sitemaps, originality, authorship, and repository release checks. Add a focused test when the new structure creates a different behavior to inspect.
When should an exception become part of the base template?
Consider a template change when several accepted exceptions reveal the same reader need or unclear default. Review the outcomes and maintenance cost before changing the template, then version the new rule and update its tests and examples.