Blog

How to Write SEO Product Requirements Documentation That Serves Stakeholders & Streamlines Projects

Published on: 
February 5, 2024
Updated on: 
February 6, 2024
by
Heather Kaeowichien
Heather Kaeowichien

As an SEO expert, you speak multiple languages. You translate the importance of projects to leadership, articulate benefits to the Marketing team, and lay out technical specifications for Product & Engineering. It’s an art form that SEO Product Managers refine over their careers, picking up different tools to help along the way. 

One of the most important communication tools in a PM’s arsenal is generally product requirements documentation. This framework distills important details of the project to stakeholders across disciplines, including KPIs, tech specs, and timelines. It also plays a key role during implementation, providing critical context for the engineering tickets that support the SEO project.

Below, we’ll guide you step by step through how to create a PRD with clear, thoughtful detail that wins stakeholders’ hearts. Plus, we’ll send you off with a free template to make your own, based on the example in the article.

What is an SEO product requirements document?

You’ve created your business cases and built your strategic SEO Roadmap. Now, it's time to start working on the individual projects. 

An SEO product requirements document (PRD) is a detailed description of a project that outlines the build and launch. It includes all of the relevant answers to questions you might expect from stakeholders across teams: the technical how-to, project scope, limitations, and business goals.

You can think of it as a combo of your business case and technical specifications — adding “how” and “when” to the “what” and “why” of a project. It’s a source of truth that not only guides the implementation of the project but also expectations around its impact. 

Perhaps most importantly, the PRD speaks vertically to all levels of the business and horizontally across peers and cross-functional partners. We’ll show you what we mean as we go through the steps, building out an example using our SEO Product Requirements Document template.

An example use case

Screenshot of the cover page of our free template: SEO Product Requirements Document
Example Product Requirements Document for an e-commerce global image optimization project.

The components of a PRD for SEO

The individual pieces of a PRD detail everything from how the project impacts business goals to relevant examples and resources from other sites. Let’s run through each section and cover approaches for a solid outcome in the PRD.

Project summary

The project summary is an outline describing the project and what’s considered in scope. To craft your summary, answer these three questions:

  • What is this project about?
  • Which areas of our software or website will it impact?
  • What are the steps involved to complete the project?

What it looks like for our use case

Screenshot of the summary section of our free template: SEO Product Requirements Document

Project goals & KPIs

This section identifies the quantitative and qualitative goals of the project, as measured by the metrics identified as key performance indicators (KPIs). It’s an important section for most stakeholders, since it indicates: 

  1. The value the project will deliver. 
  2. The priority assigned to the project based on expected results.
Pro Tip: Showcase how this work will impact the metrics that leadership monitors regularly.

What it looks like for our use case

Screenshot of the goals section of our free template: SEO Product Requirements Document

User stories

Adopting a user-first mentality means looking at each implementation through the eyes of different users who are impacted. User stories describe the expected results from the point of view of each category of user. 

As an SEO Product Manager, this presents a crucial nuance that’s unique to your role. You need to make sure that the experience of search engine crawlers holds equal consideration with other user types - such as front- and back-end users -  by creating a user story. 

Typically, it will follow this formula: 

  • As a [description of user]
  • I want [functionality] 
  • so that [benefit}
Pro Tip:  The context for the user story is usually the flip side of the problem summary. If you’re stuck on what to write, think of the problem this user encounters and what they would like to happen instead. 

Don’t discount the user story

Too often, user stories are treated like a formality just to make the engineering ask. Sometimes they’re even forgotten, poorly constructed, or incomplete. 

In reality, this exercise is the simplest common denominator for creating alignment among stakeholders and setting the tone of the project. It showcases the problem, defines the desired result, and answers the all-important question,  “Why are we doing this?”  

Sounds pretty important when you think about it that way, eh? 

What it looks like for our use case

Screenshot of the user story section of our free template: SEO Product Requirements Document

Technical implementation requirements

This section of the PRD focuses on recommendations for implementing the project — but it gets tricky when it involves technical SEO. 

Typically, a Product Manager doesn’t try to solve the problem. Engineers come up with solutions to meet the requirements and acceptance criteria. So the requirements section should focus on the end results as much as possible without overly defining how to get there.

That still stands true with technical SEO, but you’ll likely need to consult on implementation and provide more direction than the average PRD. Technical SEO is a specialized focus area and developers are often less familiar with the considerations.

Beyond how to do it, technical SEO requires specifics on what NOT to do. It’s an SEO PM’s job to identify the solutions that are unacceptable and why.

Generally, you’ll support your requirements in the references section of the PRD by including 3rd-party technical documentation (from sources like Google) and examples from competitor implementations (screenshots, links, etc.).  

Pro Tip: Consider building out this section collaboratively with the engineering team. Set a meeting to discuss what you’re trying to accomplish, showcase relevant examples, and talk through solutions together. This can help the project move more seamlessly through the development process.

What it looks like in our use case

Screenshot of the tech implementation guideline section of our free template: SEO Product Requirements Document

Acceptance criteria

This section defines the expectations of the end user by outlining the criteria for an acceptable implementation. Write the acceptance criteria (AC) as a clear and concise checklist specific to each piece of work/requirement within the PRD. (Are user needs fulfilled as defined in the requirements?)  

SEO acceptance testing can differ from that of regular user acceptance testing because it includes search engine bots as a user type. Search engine crawling happens behind the scenes, so developers might be unfamiliar with how to test the implementation. 

As part of your AC, include descriptions and access to the tools that you use to test. This empowers the development team to test their work ahead of it reaching your desk for acceptance testing.

What it looks like for our use case

Screenshot of the acceptance criteria section of our free template: SEO Product Requirements Document

Project timeline

This section is fairly straightforward. The project timeline should include the planned start and end dates for each step of the project — from writing the technical requirements to monitoring the results.

What it looks like for our use case

Screenshot of the timeline section of our free template: SEO Product Requirements Document

Supporting resources

Reference materials are crucial to build anything successfully. By providing documentation, mockups, competitor examples, research data, and more, you ensure the team has inspiration and examples to guide their work. It also helps support the criteria you outlined in the technical requirements.

Link to:

  • Competitor examples
  • Design mockups (if applicable and available)
  • Previous versions of this feature (including related tickets or releases)
  • Data analysis
  • Research
  • Third-party supporting documentation

What it looks like for our use case

Screenshot of the supporting material section of our free template: SEO Product Requirements Document

Considerations and risk

This is the section that will address “everything else” — basically, all of the other things that were considered when defining the project. Namely, that’s the known risks and considerations, like what’s out of scope. 

In your write-up, include subsections for Assumptions, Risks, and Out-of-Scope:

Assumptions - Describe any assumptions you made when writing the requirements. It helps to ask yourself:

  • Are you assuming other roadmap items will be completed before this project?
  • Is this project a blocker or prerequisite to any other project?
  • Are you assuming this will be completed by a particular time for a particular reason?

Risks - Exactly as in your SEO business case, this should include both sides of risk. What’s the risk if you do this, and equally important, the risk if you don’t?

  • If we DO implement this…
  • If we DON’T implement this…

Out-of-Scope - Define related items that were considered but not included in the project.

  • Which areas of the site or software are similar or closely linked but not included?
  • Which technical elements are left out of this project? 
  • Which relevant areas are already addressed by other projects?
Pro Tip: One of the best ways to build this section is by reviewing the document with key stakeholders. Often their questions will bring up something that should be in-scope or out-of-scope.

What it looks like for our use case

Screenshot of the considerations and risks section of our free template: SEO Product Requirements Document

Use the PRD for streamlined collaboration with Product & Engineering

Once it’s finalized with relevant stakeholders, the SEO PRD has the information you need to effectively collaborate with engineering. The rich format of the SEO PRD (as compared to basic user stories) enables you to create detailed tickets, so engineers can pick up the work and run with it. 

The PRD will likely become an epic and each work item will turn into an engineering task or user story. 

SEO epic ticket

The PRD translates into an epic within your engineering task management system. An epic represents a group of related work items that share a strategic objective and break down into specific tasks — aka the requirements you’ve outlined in your PRD. 

The epic is effectively a table of contents for related work in the past, present, and future. This way, all related tickets and resources - whether they’re outlined in your PRD or future bugs/optimizations - are grouped in one place.

SEO engineering tickets

Each engineering ticket is a user story. The user stories you developed (each of the “wants” from impacted users) in the PRD will become an individual SEO engineering ticket that is linked to your epic. 

The SEO engineering ticket will include the following sections from your PRD as relevant to the specific user want:

  • User story
  • Technical implementation recommendations (if applicable)
  • References
  • Acceptance criteria

Create a partnership for dedicated resources

Engineering teams usually work in short periods called sprints, which allow them to track the amount of work being pulled into a sprint versus the resources available in that time. “Story points” are the units of measurement used to tabulate those resources.

Your goal as an SEO Product Manager should be to create a partnership with Product and Engineering that guarantees a consistent dedicated number of story points or hours (however your team works) per sprint or program increment. 

Establishing an expectation of the SEO work that will be coming through the Product and Engineering pipeline helps prevent regular negotiations for development support. It also sets a pace and tone for when everyone can expect to see progress and releases.

Of course, each party needs to be flexible from time to time, scaling up or down based on larger company needs.

Remember: The PRD is a living, breathing document

The PRD will be a working document as the project progresses through each phase. It might update or change as new context or curveballs pop up throughout the project. For example, Engineering may hit a roadblock that materially impacts the size and scope of the project. Or, a new priority may impact prioritization and alter the timeline. 

No matter what happens, the team will be well-equipped to handle it thanks to the well-researched and -planned foundation you created in your PRD. Don’t forget, our free template is here to help get you started!

Need help connecting the dots between SEO & Engineering?

Explore Product Management Services →

Work With Us
We’ll help craft, teach, and carry out SEO roadmaps that check all the boxes.
CONNECT THE DOTS WITH US