How to Write Technical SEO Tickets Developers Can Implement and Test

A technical SEO ticket should clearly define an observable change to a specific page or component, provide evidence proving the change, and maintain existing behavior. This gives developers a clear delivery target and enables reviewers to repeat the test. For instance, improving internal linking on product pages requires specifying the exact page, the missing behavior, and why it's useful for customers.

Consider a boot retailer with a product page at /products/leather-walking-boots/ and a care guide at /guides/boot-care/. The ticket title could be: Link the product care section to the boot-care guide. The description should identify the source page, the component owning the change, the destination, and the reason a customer would use it.

For the implementation, the expected output is ordinary link markup, with the anchor element containing an href attribute. The link label should be meaningful, such as "Read the boot-care guide." The ticket should also specify acceptance criteria, ensuring the link is visible and usable on different devices and that it opens the correct guide when activated.

Before implementation, write acceptance criteria outlining the exact link label, its rendered href, and the expected behavior when activated through keyboard or mouse. After implementation, verify the link's presence, destination, and activation behavior in the care section and ensure no existing controls have been affected.

It's crucial to bound the regression test by understanding the ownership of the change. If the change only affects the care section and not other components, the test can focus solely on that section. However, if the change impacts multiple areas, the test should consider the broader impact. This approach aligns with spec-driven development principles, emphasizing the importance of defining verifiable requirements before coding.

For this link ticket, retain the original care-section view, the relevant configuration or code difference, the rendered anchor, and the public after view. Each of these pieces of evidence addresses a different aspect of the requirement: the original view shows what was there, the difference highlights the change, the rendered anchor identifies the element and destination, and the public view demonstrates the visitor's experience.

By separating these evidence views, you can ensure a comprehensive understanding of the change and its implications.