An SEO handoff is the point at which a recommendation becomes a change a developer can build and somebody else can test. A useful ticket specifies the affected pages, current behaviour, required output, exceptions and evidence needed for approval. A list of SEO problems alone is not a development specification.
This checklist is for developers and the SEO teams briefing them. It covers a single template fix, a website release and the situations that often get missed: filtered URLs, empty states, staging restrictions and differences between server responses and rendered pages. Writers and editors have separate handoff responsibilities; this guide deals with implementation and verification.
Start with a testable requirement, not an audit warning
A crawler might flag missing canonicals across category URLs. That tells the team where to look, but not what the application should produce. Should the category be indexable? What happens when a filter is applied? Is a pagination URL showing a distinct set of products? The SEO owner needs to answer those questions before an engineer chooses the rule.
Describe the user or search risk proportionately. Conflicting canonical signals may complicate Google’s selection of a representative page; they do not automatically prevent indexing. Missing structured data may remove eligibility for a specific supported rich result, not for Google Search generally. A missing image alt attribute can be an accessibility or image-discovery problem without proving an organic traffic decline.
At minimum, record the URL pattern, existing output, expected output, exceptions, validation method and the person responsible for sign-off. Technical SEO fundamentals explain the underlying search mechanisms, while this page describes how to turn them into development work.
Five decisions before a ticket is ready
- Scope: Identify the URLs, components, templates, environments, languages and exclusions involved.
- Evidence: Provide an example of the actual fault, how it was detected, and any uncertainty about its impact.
- Expected state: Describe the intended HTTP status, HTML output, canonical, links, interaction or other observable behaviour.
- Acceptance criteria: State the conditions that determine pass or fail, including relevant edge cases.
- Ownership: Assign implementation, staging QA, production approval and monitoring.
The SEO development ticket: a worked example
Consider a hypothetical ecommerce release introducing a new category template. Its canonical output is undefined, and the same component serves base categories, filtered views and paginated results. A ticket saying only “add canonical tags” would risk applying one rule to several different page types.
| Field | Ticket content |
|---|---|
| Objective | Give indexable base categories a consistent, absolute self-referencing canonical in the HTML head. |
| Affected scope | English and German base-category templates; other content types excluded. |
| Current state | The new template does not output the approved canonical. Filtered and paginated variants have not yet been specified. |
| Dependencies | SEO owner must approve separate filter and pagination URL rules before release. |
| Acceptance | One intended canonical, correct HTTPS host, final 200 destination, no test host or tracking parameters; matching sitemap and internal-link conventions where relevant. |
| QA | Inspect raw and rendered HTML on representative category states in staging; retest production after deployment. |
| Owners | Engineering implements; SEO validates indexing requirements; release owner verifies deployment. |
The example is illustrative, not a description of a MOCOBIN client project. It also does not authorise canonicalising every filtered or paginated URL to the first page. Google advises unique URLs and appropriate canonicals for distinct pages within a paginated sequence. The team must determine whether a filter is a useful separate landing page or a redundant URL variation before writing the rule.
For changes involving image data, titles or structured data, identify their source fields and fallback rules. An acceptance criterion should say what the page actually returns, not merely which CMS field has been filled in.
Use a page-state matrix to catch exceptions
Many handoff failures occur because the ticket describes the ideal page and nobody tests the alternatives. But it would be equally wrong to insist on identical metadata and schema in every state. A real 404 has a different job from a valid product detail page.
| Page state | What the ticket should decide | What QA should verify |
|---|---|---|
| Valid content | Indexability, canonical URL, metadata, main content and required links. | 200 response, intended output and crawlable discovery paths. |
| Empty category | Whether the page remains useful and indexable, or needs a different treatment. | Accurate message, status, robots rule and no unsupported structured data. |
| Filters and sorting | Which URL combinations deserve separate search results; how others are controlled. | Expected canonicals, crawl rules and valid internal links, with no accidental infinite URL space. |
| Pagination | Distinct page URLs, link paths and representative canonicals. | Page two is not automatically canonicalised to page one when its content differs. |
| Loading or interactive content | What essential information is available without a user click or scroll. | Initial response and rendered DOM contain intended content and links. |
| Moved or missing content | Relevant permanent redirect, or genuine 404/410 when no replacement exists. | Server status and destination match the actual situation, rather than a visual error page returning 200. |
A generic instruction to “preserve SEO tags in every state” is not enough. Define the correct state-specific response first. For instance, a valid category page and an unavailable resource should not be forced to share the same indexing rules.
Technical requirements worth specifying explicitly
Crawling, indexing and canonicalisation
Document expected HTTP status codes, robots directives, canonical URLs, redirects, sitemap inclusion and how query parameters are treated. Google must be able to crawl a page to process a noindex directive; a simultaneous robots.txt block can prevent that. Canonicals are hints for duplicate and very similar URLs, not redirects or a remedy for poor content. Consult Google’s noindex guidance and canonical guidance when specifying the output.
Rendering and internal navigation
If the site uses JavaScript, define what is present in the initial server response and what appears after rendering. Check canonical consistency between the two, ensure important navigation uses normal links with valid href values and identify content that depends on user interaction. Google’s JavaScript SEO documentation provides implementation details. Link handling also needs to account for responsive navigation and localisation.
Structured data, metadata and images
Specify title and description templates, fallback rules, structured-data fields and their CMS sources. Markup must accurately describe visible content. A missing supported rich-result property can be worth fixing, but schema is not a universal prerequisite for ranking or appearing in generative AI search. For images, identify which need descriptive alt text and which are decorative, and establish dimensions or loading priorities where they affect layout or user experience. See MOCOBIN’s structured data guide for the separate implementation detail.
International pages
Specify real language or regional URL relationships, valid hreflang codes, return links where applicable and the interaction with canonicals. Do not assume every translated page should canonicalise to English. Check generated annotations against actual localised URLs, not placeholder market codes. MOCOBIN’s hreflang guide covers language-targeting rules in detail.
Performance and accessibility
A request to improve speed needs a baseline, defined metric, page sample, testing environment and acceptable regression range. Google’s recommended Core Web Vitals “good” thresholds are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, typically assessed at the 75th percentile of real-user visits. They are not a blanket requirement that every Lighthouse run score above 90 or that every server respond within 200 milliseconds. Lighthouse is diagnostic laboratory evidence; field data, when sufficient, shows actual user experience. See Google’s Core Web Vitals explanation.
Use semantic HTML and meaningful link and image alternatives for people first. Correct native elements such as button and nav are often better foundations than custom div controls covered in ARIA attributes. Accessibility checks belong alongside SEO QA where they overlap, but ARIA labels are not established direct ranking shortcuts.
Separate staging checks from production approval
Staging is where the team can find defects before they affect live URLs, but it is not proof that production will behave identically. Data sources, caches, content security policies, consent tools and domain settings may differ. A test plan needs both stages.
Before release
- Sample every affected template and the page states documented in the ticket.
- Check raw HTML and rendered HTML when JavaScript affects metadata or main content.
- Test status codes, redirects, canonicals, robots directives, internal links and supported structured data.
- Validate language annotations and navigation variants where the release affects more than one market.
- Verify that staging remains appropriately protected from indexing without blocking authorised QA.
- Record results and unresolved exceptions against the acceptance criteria, not a single tool score.
Authentication or network restrictions can protect a staging site from public access. A simple robots.txt block is not a dependable method of keeping discoverable staging URLs out of Google’s results, and it can hide a page’s noindex from crawlers. Choose the staging protection to suit access and testing needs.
After deployment
- Check representative live URLs and their final HTTP responses.
- Confirm production canonicals, internal links, sitemap entries and structured data do not reference staging.
- Verify that temporary
noindexrules, test redirects and blocked resources were not carried into production. - Compare the deployed release with its ticket, including any exceptions approved during QA.
- Use Search Console and crawl evidence later to review how Google processed the change, without equating successful deployment with immediate indexing or ranking improvement.
Check crawling separately from indexing. The Crawl Stats report describes Googlebot requests and host responses, while Page indexing explains a different part of the process. Neither is a substitute for confirming the actual page output.
How to close a handoff without losing the decision
The final approval should record what was released, which URLs and states were tested, who accepted the result, and what remains to monitor. A developer’s ticket can be complete when the implementation passes its specified checks even if search traffic has not yet changed. A later indexing review or performance assessment can remain a separate follow-up item.
For a larger team, keep a small master checklist with optional modules for migrations, international pages, faceted navigation and JavaScript applications. Give the rules a version and owner. Avoid copying long generic instructions into every ticket when a link to the approved standard and a few page-specific exceptions would be clearer.
The useful handoff is the one that lets a colleague answer a specific question: What should this URL return, and how will we know whether the implementation matches that decision? If the ticket cannot answer it, more checkboxes will not solve the problem.
