SEO

SEO acceptance criteria for a build

Use when a feature is already in development and you need SEO requirements a QA tester can actually check.

seo-acceptance-criteria-brief.md

Download .md

You are writing SEO acceptance criteria for a feature already in development. You are not designing the feature.

What is being built: {{FEATURE_DESCRIPTION}}
Stack, rendering method and CMS: {{TECH_STACK}}
Templates and URL patterns it touches, and any new URLs it creates: {{AFFECTED_TEMPLATES}}
The existing definition of done: {{DEFINITION_OF_DONE}}

Output four numbered sections.

1. Criteria table: ID | Criterion written as given, when, then | Why it matters | How QA verifies it | Severity (Blocker / Should / Nice to have). Cover URL format and casing, status codes, canonical tags, where the title and H1 come from, meta robots, internal links into any new pages, pagination, whether the content sits in the served HTML given {{TECH_STACK}}, structured data, sitemap inclusion, and what happens to any URL this replaces.
2. "Out of scope" - what this ticket must not try to fix, so the criteria stay shippable.
3. "Questions for the team" - anything in {{FEATURE_DESCRIPTION}} too vague to write a criterion against, each with the two or three possible answers and what each would change.
4. A pre-release check list mapped to each pattern in {{AFFECTED_TEMPLATES}}.

Constraints:
- Every criterion must be verifiable by someone who is not an SEO. If you cannot state the check, it is not a criterion.
- Do not restate anything already in {{DEFINITION_OF_DONE}}. Name it as covered and move on.
- Mark as Blocker only what would cause de-indexing, duplication or lost links.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{FEATURE_DESCRIPTION}}
{{TECH_STACK}}
{{AFFECTED_TEMPLATES}}
{{DEFINITION_OF_DONE}}

Getting a better result

Write these before the sprint starts; criteria added at QA get argued away as scope creep.
Name the rendering method, since the served HTML criterion is the one most often silently failed.
Keep the questions section short and answerable, or the ticket stalls waiting on you.

Questions about this prompt

When do I write these rather than review the feature at QA?

Before the sprint starts, while requirements are still requirements. An SEO problem raised at QA arrives as new scope and gets argued away or deferred. The prompt assumes the feature is already designed and does not try to redesign it, which is what makes the criteria shippable rather than a fight.

What do I need from the team first?

The feature description, the stack and rendering method, every template and URL pattern it touches including new URLs, and the existing definition of done so criteria do not repeat what is already covered. Name the rendering method explicitly; the criterion about content being in the served HTML depends on it.

What comes back?

Given, when, then criteria with a severity, an out of scope list, questions for the team, and a pre-release checklist per template. The column that decides whether any of it survives is how QA verifies it: a criterion only you can check is not a criterion, it is a preference someone will skip.

What is the mistake that costs me here?

Marking everything a blocker. The prompt reserves that for de-indexing, duplication and lost links, and for good reason: a list where every row blocks release gets rejected as a whole and you lose the ones that mattered. Keep the questions section short too, or the ticket stalls waiting on you.