Anatomy of a great SEO ticket

0:00 Anatomy of a great SEO ticket

Most SEO recommendations are never implemented. Not because developers don't care, but because they receive requests like fix canonicals or improve site speed. You can't estimate that, test it or close it. In this lecture you'll learn the anatomy of a ticket developers actually act on: a template, worked tickets for Kiran Home's biggest root causes, how to write binary acceptance criteria, including Given-When-Then scenarios, and how to size and split work.

0:31 The ticket template

A good ticket reads like a small specification. What's wrong, where, why it matters, exactly what should change, and how to prove it's done. The template in the lesson text has a title in the form SEO, component, specific change. Type and priority from your roadmap score. A one or two sentence summary a non-SEO can understand. Business impact. Current behaviour with two to five example URLs. Expected behaviour, including edge cases. Acceptance criteria. How to test. Out of scope. Dependencies and risks. And references to documentation and evidence IDs.

1:10 Ticket 1: RC1 canonicals

Let's look at ticket one, for root cause one. Title: product and journal templates, canonical must self-reference the current market URL. Summary: pages in the Pakistan and UAE folders set their canonical to the UK equivalent, so Google treats them as duplicates and shows UK pages with pound prices. Current behaviour, with an example URL. Expected behaviour: the canonical equals the page's own absolute URL, https, www, current market folder, no query string, lowercase, and the site's trailing slash rule. Parameter variants canonicalise to the clean URL of the same market. hreflang unchanged.

1:50 Ticket 1: acceptance criteria

The acceptance criteria for ticket one are binary. For every product and journal URL in each market, the rendered HTML contains exactly one canonical link in the head, equal to its own clean URL. The canonical is present in the server-rendered raw HTML, not only after hydration. No canonical points to a URL that redirects or returns non-two-hundred. And an automated test is added to the template test suite. Then how to test: a curl command against staging, and a list crawl checking canonical equals address.

2:27 Ticket 2: RC2 facets

Ticket two, for facets. Expected behaviour: filter options for size, price, sort and multi-select combinations update the listing without outputting crawlable anchor links; brand and colour filters on the approved list keep clean static URLs. Parameter order is normalised. Zero-result combinations return four-oh-four. And robots.txt adds disallow rules for the low-value parameters and search, but only after another ticket confirms no approved facets use them. Acceptance: no anchor hrefs with those parameters in the rendered HTML, approved facet pages self-canonical with unique titles, and zero-result combos returning four-oh-four.

3:05 Ticket 3: RC8 in Gherkin

Ticket three, for the CDN bot rule, is a great place to use Given-When-Then scenarios, which QA teams can automate. Given a request from a verified bot's IP, and a user agent containing its token, when it requests a public product URL, then the response is two hundred and no challenge page is served. The examples table lists Googlebot, Bingbot, OAI-SearchBot and PerplexityBot. And a second scenario confirms protected paths like account and checkout stay protected. Pair it with the written AI crawler policy, so the rule is a business decision, not an SEO whim.

3:46 Good acceptance criteria

What makes acceptance criteria good? They're binary, pass or fail, and checkable by a QA engineer without SEO knowledge. Good: returns HTTP four-oh-four for zero-result combinations. Bad: handle empty filters properly. Good: the LCP image on category templates has no loading lazy attribute and has fetchpriority high. Bad: improve LCP. If a tester can't tell whether it passed, it isn't an acceptance criterion.

4:13 Why, briefly; size and split

Give developers the why, briefly. Link to Google's documentation on canonicalisation, faceted navigation or redirects, and keep the explanation short. Developers respect specificity; long SEO essays inside tickets get skipped. And size and split. If a ticket would take more than a sprint, split it by template or by market. Tickets that ship independently deliver value sooner and are easier to roll back.

4:40 Example 2: rewriting a vague ticket (illustrative)

Worked example two, illustrative. A Lahore agency's junior writes a ticket: fix hreflang issues on the site. The developer asks five questions and parks it. Rewritten, it becomes: product template, hreflang set must be complete and reciprocal. Three example URLs with current output. Expected behaviour listing the four market codes plus x-default, absolute URLs, self-reference, and targets that return two hundred and are self-canonical. Acceptance criteria as a checklist plus a crawl-based test. Out of scope: journal templates, in a separate ticket. It was estimated and shipped the next sprint.

5:19 Common mistakes

Common mistakes. Tickets without example URLs. Expected behaviour that ignores edge cases like parameters, trailing slashes, uppercase and pagination. Mixing several unrelated fixes into one ticket. And not specifying whether a tag must be in the raw HTML or can be added client-side. Each of these leads to questions, delays or a fix that doesn't work for Google.

5:44 Watch me do it: writing the RC8 ticket

Watch me do it. I'll write the RC eight ticket from scratch in ten minutes. Step one: the title. Square brackets SEO, CDN bot rules: allow verified search and AI search crawlers on public paths. Step two: the summary, in plain language. Since the relaunch, Cloudflare challenges Bingbot and some AI search crawlers on product pages, so Bing dropped many products and AI assistants can't read them. Step three: business impact, with evidence IDs E twelve and E thirteen. Step four: current behaviour, with two example URLs and a firewall event screenshot. Step five: expected behaviour. Verified Googlebot, Bingbot, OAI-SearchBot and PerplexityBot receive two hundreds on public paths; account and checkout stay protected; training crawlers follow the written policy. Step six: acceptance criteria, as the Gherkin scenarios from the lesson, including the protected-paths scenario. Step seven: how to test: filter firewall events for verified bots after deploy, and confirm zero challenges on public paths over forty-eight hours. Step eight: out of scope: changes to rate limiting for abusive bots. Step nine: risk and rollback: low; revert the rule. I link the AI crawler policy, and I ask the developer to estimate it rather than guessing myself.

7:09 Raw HTML or client-side?

A word on where the tag must live, because it's the most common source of back-and-forth. For anything search engines must see reliably, like canonicals, robots meta, hreflang and structured data, specify that it must be in the server-rendered raw HTML. Client-side injection adds rendering risk and can create raw versus rendered mismatches, and remember that a noindex in raw HTML may stop Google rendering at all. Say it explicitly in the expected behaviour and in the acceptance criteria. Developers can't guess this requirement, and many frameworks make the client-side path the easy default.

7:50 Recap and try this now

Recap. Write tickets as small specifications: specific title, plain-language summary, business impact, current versus expected behaviour with examples and edge cases, binary acceptance criteria, how to test, scope and risks. Use Given-When-Then when QA will automate. Try this now. Take the vaguest SEO request in your backlog and rewrite it with the template, including at least three example URLs and four binary acceptance criteria.