---
name: step-6-write-title-and-headings
description: "Write a clear title and useful section names. Help readers see what your page will teach."
category: Content Factory — Process
stage: Process
definitive_article: https://localservicespotlight.com/article-guidelines/
status: complete
---

# Step 6: Write title and headings

A clear title helps the right reader choose your page. Good section names help them find the answer. Start with what the article really teaches, then name that promise in plain words.

**The path:** Real article promise → Clear title → Useful headings → Checked search preview.

**Use this when:** The article body is drafted and needs its visible title, section headings and search description.

## Inputs
- The full draft, [Goals, Content, and Targeting](https://blitzmetrics.com/gct-business-strategy/) brief and reader’s main question.
- The current site title convention, existing URL/title if updating, and intended author voice.
- The actual WordPress/template title behavior and search-preview tool when available; a character counter is only an editing aid.

## First-run prompt

> Write a truthful title, search description and heading map from this full article and GCT. Use the reader’s words naturally. Treat 60/160 as optional house drafting targets, not Google limits. Check heading promises and the existing template before adding an H1; keep the current canonical URL.

## Steps
1. Read the article and write one sentence stating what it delivers. Reject title options that promise results, speed or certainty the source cannot support.
2. Draft a clear visible title using the reader’s natural words. Keep it concise and distinct from other pages on the site. Do not rename an established URL just because the title improves.
3. Write a search-title version only when the site uses a separate field. The old under-60 rule can serve as a house drafting target, but Google has no fixed title character limit and may choose different title text. Judge the actual preview and meaning.
4. Write a concise meta description that explains the useful answer. The old under-160 target is not a Google limit or a guarantee of what appears; Google may use the page’s own text. Avoid unsupported offers or results.
5. Make each H2 describe the section’s real answer. Use H3 for a true subtopic under that H2. Use natural variants of the question where helpful, without a quota of keywords in headings.
6. Check the visible page structure: one clear article H1 under the site’s publishing standard, logical H2/H3 nesting, and no fake headings made only by bold text. Existing templates can supply the H1, so avoid duplicating it in the body.
7. Read the headings alone like a contents list. Check that each promise is fulfilled in its section and the order makes sense. Preserve useful source-specific detail without clickbait.
8. Save visible title, optional SEO title, description and final heading outline in named fields. Pass them to the hook writer and later search-metadata task with any template preview check still pending.

## Definition of done (QA checklist)

- [ ] Title and description accurately represent the article without unproved promises.
- [ ] Headings make a clear, logical map of actual section content.
- [ ] Visible H1 and template behavior are checked or specifically pending.
- [ ] Preview length is treated as a display/editing concern, not a Google ranking requirement.

## Example(s)

**Fictional teaching example — no page was changed.** For the sample photo checklist, use the title “What photos help with a bike repair quote?” The headings are “Show the whole bike,” “Show the issue up close,” and “Explain when it happens.”

A matching description is: “See which bike photos and notes help a shop prepare for your visit, and why a final quote may still need an inspection.”

“Exact bike repair prices in five minutes” is rejected because the article cannot deliver that promise. If the template already prints the page title as H1, the article body begins its sections at H2.

## Handoff and Content Factory context

The writer uses these fields for [Step 7: write the opening](https://local-service-spotlight.github.io/task-library/?task=step-7-write-hook-and-establish-context#task-step-7-write-hook-and-establish-context). The publisher later enters checked search fields in [Configure search metadata](https://local-service-spotlight.github.io/task-library/?task=step-14a-configure-rankmath-seo-plugin#task-step-14a-configure-rankmath-seo-plugin) when that plugin is used.

Produce supplies the real source. **Process**, this stage of the [Content Factory](https://blitzmetrics.com/content-factory/), turns it into useful finished assets. Post saves or publishes them on the agreed channels. Promote tests and distributes suitable work within its own scope. The handoff above names this task’s actual next step; catalog neighbors alone are not prerequisites.

## When this runs

Once per article title/heading pass; recheck after a meaningful change to the article’s scope.

## First-run setup and continuity

Open the supplied task file and its linked source. Verify the project’s real inputs, account, access and output folder before work. This Markdown file is a guide; it does not install an app, connect an account, supply a subscription or create a schedule. Carry out work already authorized; do not ask for the same approval again. Keep any unsupplied destination or new action outside that scope clearly pending.

Save source IDs, versions, decisions, checked outputs and next owner in the project tracker. Before a retry, check the saved state and other workers’ changes. A model name does not guarantee memory or a running timer. Repeated work needs an actual configured trigger and durable state; one-off work can be started by the prompt above.

Keep agent media muted with volume zero before playback. If mute cannot be verified, use captions, metadata or still frames. State the limit: silent visual checks do not prove spoken-word accuracy or audio quality. Do not start sound through the user’s speakers unless explicitly asked.

## Write up the real run

For every actual attempt, [write its meta article](https://blitzmetrics.com/meta-article-prompt/) with this recipe and revision, trigger, steps performed, output evidence, measured result, gaps and next owner. Failed, blocked and partial attempts also get a written record. A draft can satisfy writing; publishing it follows the existing job scope.

Keep one stable execution ID across retries and edits. A separately scoped child task may have its own ID linked to its parent. Writing the parent’s meta record is part of that run, not an endless new chain. The [recipe and meta-article guide](https://localservicespotlight.com/meta-articles/) explains this distinction. Teaching examples are not real executions and must not enter the run count.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** Process
- **Importance:** 4/5 `●●●●○` — frequency 4, revenue 3, gating 2 (runs every factory cycle or weekly)
- **Suggested previous station:** `run-overnight-local-writer`
- **Suggested next station:** `step-7-write-hook-and-establish-context`
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Process-stage artifact examples include `transcript.md`, `gct.md`, `article.html` (or a staged draft), `clips/`, or `04-Promote-Creatives/`. These are examples, not requirements for every task. Follow this task's actual Inputs and Handoff sections for the required output, evidence, and next owner. Pass the files or records, not one vendor's memory.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- Canonical article: https://localservicespotlight.com/article-guidelines/
- Exact task: [Step 6: Write title and headings](https://local-service-spotlight.github.io/task-library/?task=step-6-write-title-and-headings#task-step-6-write-title-and-headings)
- Writing standard: [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Google’s title-link rules](https://developers.google.com/search/docs/appearance/title-link)
- [Google’s snippet rules](https://developers.google.com/search/docs/appearance/snippet)
- [WordPress block-editor controls](https://wordpress.org/documentation/article/wordpress-block-editor/)

## Review and evidence still needed

The source contributor status is preserved. It is not certification of this draft or proof of account access, completed work or a live outcome. The worked example teaches the method and is explicitly fictional.
- The actual site template and search preview need real page inspection; search display is not guaranteed.