SEO requirements for developers
How to write SEO requirements developers will build: ticket format, acceptance criteria, and the technical detail behind redirects, rendering and schema.
SEO requirements for developers work best written as ordinary tickets: a clear ask, the technical detail behind it, and acceptance criteria an engineer can test without needing SEO context of their own. A request with no acceptance criteria reads as a suggestion, and suggestions lose to features every sprint.
Getting this right is one piece of enterprise SEO that has nothing to do with content or keywords and everything to do with how work actually gets built on a large site.
On this page
What do developers actually need from an SEO ticket?
The same things they need from any other ticket: a clear problem statement, the specific technical change required, and a way to know when it is done. What most SEO tickets are missing is the third part. "Improve our canonical tags" is a direction, not a requirement, and an engineer reading it has no way to know whether their change satisfies it.
Write the ticket the way you would write any other spec: current behavior, desired behavior, and the test that proves the gap is closed. The SEO reasoning belongs in the description for context, not as the only content of the ticket.
This matters more than it sounds like it should, because most engineering teams prioritize by clarity as much as by importance. A ticket that states exactly what to change and how to verify it gets picked up alongside ordinary feature work. A ticket that reads as a general instruction to "improve SEO" sits in the backlog indefinitely, not because engineers do not care about search, but because nobody can tell what finishing it would even look like.
The person writing these tickets does not need to be a developer, but they do need enough technical fluency to speak the language of a spec rather than the language of a recommendation. That is usually the single most valuable skill on an enterprise SEO team, and it is worth hiring or training for directly rather than assuming any senior SEO person can do it well by default.
How do you write a ticket an engineer will actually pick up?
State the current and desired behavior
"This template currently returns a 200 status with duplicate content; it should return a single canonical tag pointing to the primary URL."
Name the exact scope
One template, one route pattern, or a specific list of URLs. "The whole site" is not a scope an engineer can size.
Give the technical detail, not just the goal
Link the exact spec or standard involved, so the engineer is not left guessing at implementation.
Write acceptance criteria as a test
A specific check that passes or fails, ideally one that could run in an automated test suite.
Name who reviews it before it ships
So the ticket does not get marked done based on the engineer's own judgment alone.
What are the most common SEO tickets, and what do they need?
Most large-site SEO tickets fall into a handful of repeating types, and each has a different kind of technical detail behind it.
| Ticket type | What it needs technically | How to test it's done |
|---|---|---|
| Redirect implementation | A single server-side 301, no chains | Fetch the old URL; confirm one hop to the final destination |
| Canonical tags | One canonical URL per page, in the page head | View source; confirm exactly one canonical tag, pointing correctly |
| Structured data | Valid markup matching the content on the page | Run a structured data test; confirm zero errors |
| Robots directives | Correct allow or disallow rules by path | Fetch robots.txt; confirm the rule matches the intended paths |
| Server-side rendering | Key content present without executing JavaScript | Fetch with JavaScript disabled; confirm the content is there |
How do redirects need to be implemented correctly?
As a single, permanent, server-side redirect, pointed straight at the final destination. A 301 status code tells a search engine the move is permanent and that ranking signal should transfer to the new URL, but that signal weakens with every extra hop in a chain [3]. "A redirects to B redirects to C" is a common and avoidable mistake, usually caused by redirect rules accumulating over several unrelated projects without anyone reviewing the full chain.
Test redirects the way a crawler would: fetch the old URL directly and confirm it returns exactly one redirect, to the exact final destination, with no intermediate hop.
What does "server-rendered" mean, and why does it matter here?
It means the meaningful content, price, main copy, key links, exists in the HTML a server returns, before any JavaScript runs in a browser. Content that only appears after client-side script execution can be slow to index or missed by some crawlers entirely, and on a large site built from one template, that risk applies to every page built from it at once.
The acceptance test is simple to specify and simple to run: fetch the page without executing JavaScript and confirm the content that matters is present in the raw response.
200ms INP threshold
How should structured data be implemented?
As machine-readable markup that accurately describes what is already on the page, added in a format a search engine can parse, like JSON-LD embedded in the page [2]. Structured data does not itself change rankings; it helps a search engine understand a page's content correctly and can unlock specific visual treatments in results.
Write the acceptance criterion as a validation pass, not as "schema is added": the markup for a given template should pass structured-data testing with zero errors and accurately reflect the visible content on the page, checked against a sample of real pages, not just one clean example.
How does robots.txt fit into a developer ticket?
As a small, precise file that needs the same care as any other production config, because a single misplaced rule can block an entire section of a site from being crawled at all. Robots.txt controls which paths a crawler may request, not whether a page appears in search results once it is known about some other way [4].
Any ticket touching robots.txt needs an explicit before-and-after diff and a fetch test against the live file after deployment, because this is one of the few SEO mistakes that produces no visible error and no obvious signal that anything went wrong. A staging environment blocked from all crawling by default is normal and correct; the same rule shipped to production by accident, unnoticed for weeks, is one of the more expensive mistakes an engineering team can make on a large site, precisely because nothing about it looks broken from the inside.
What acceptance criteria actually make a ticket testable?
Write them as a statement someone other than the ticket's author could check and get the same answer. "Redirects are set up" depends on who is reading it and what they assume "set up" means. "Fetching /old-path returns a single 301 to /new-path, with no intermediate hop" does not depend on interpretation at all.
Where possible, turn the acceptance criterion into an automated check rather than a manual one. A redirect test, a structured-data validation check, or a fetch-without-JavaScript test can all run in a continuous integration pipeline once written down clearly enough to specify, which means a future release cannot silently undo this ticket's fix without someone noticing immediately rather than months later.
How does this connect to governance and team structure?
Well-written tickets are what SEO governance actually depends on to work day to day: a review step means nothing if the thing being reviewed is too vague to evaluate. And someone on the team needs to own writing these tickets as part of their actual role, which is one of the positions SEO team structure sets out directly.
If you are trying to get engineering time approved for this work in the first place, the SEO business case shows how to size and justify that ask in terms a budget owner, not an engineer, will accept. Bring a handful of tickets written to this standard into that conversation; a concrete example of exactly what the requested sprint capacity would build is a far easier ask to approve than a general request for "developer support."
Questions people also ask
Why do SEO tickets get deprioritized by engineering so often?
Usually because they are written as a request rather than a spec: no acceptance criteria, no test steps, no way for an engineer to know when it is actually done. A ticket that reads like a normal feature ticket competes for priority on the same terms as one.
What is the single most common SEO implementation mistake developers make?
A redirect chain: URL A redirects to B, which redirects to C. Each extra hop adds delay and can dilute how much of the original page's ranking signal reaches the final URL, so every redirect should point straight at its final destination.
Does structured data actually change rankings?
Not directly. It helps a search engine understand what a page is about and can unlock specific visual treatments in results, but adding it does not itself guarantee any ranking or display change.
What is an acceptance criterion for an SEO ticket, in practice?
A specific, checkable statement of done: this URL returns a single 301 to this exact destination, or this template's product pages pass structured data validation with zero errors. Not "redirects are set up" or "schema is added."
Sources
- Web Vitals — web.dev, Google (checked 23 September 2026)
- Intro to how structured data markup works — Google Search Central (checked 23 September 2026)
- 301 redirects — Google Search Central (checked 23 September 2026)
- Introduction to robots.txt — Google Search Central (checked 23 September 2026)
Get SEO tickets your engineering team will actually ship
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Ibrahem HelalCo-founder
Leads strategy and delivery.
Works on: SEO, GEO
Reviewed before publishing by Jeremy Zava, Co-founder.
- Enterprise SEO: the buyer's guide for 2026Enterprise SEO is search work for large sites and large teams: what it covers, what it costs, who owns it, and how to prove it pays back.
- SEO governance: what it is and how to run itSEO governance is the rules, reviews and owners that stop a large site from undoing its own search work. What to write down, who owns it, and how to enforce it.
- How to build the SEO business caseHow to build an SEO business case that survives a finance review: the numbers to lead with, how to model the timeline, and a worked hypothetical example.
- SEO team structure: the roles and hiring orderThe roles an enterprise SEO team actually needs, what each one owns, the order to hire them in, and how team size should scale with site size.