Stop asking engineering for favors: Give them an SEO PRD
Some organizations already use a PRD process, so this post should encourage you to adopt it. Other organizations don’t, and in that case, you can’t go wrong by professionalizing with a PRD
This week’s newsletter is sponsored by North Star Inbound and Semrush Enterprise
Paid subscribers can download the accompanying PRD template
If you’ve ever sent a Slack message to a developer that said something like “when will the canonical link on the new PPC landing page be added,” and then watched it remain unread for three weeks, this is for you.
The problem with most SEO fixes isn’t that they’re hard to implement. It’s that the ask was set up wrong. The SEO team was making an SEO request that very likely does not fit the template the engineering team is used to seeing, so you are already at a disadvantage before the conversation even starts.
[Sponsored by Semrush Enterprise]
Feature your brand in all the right answers
Discover how Semrush Enterprise helps brands like Square 10X their productivity to leave competitors behind in SEO and AI search. Our clickthrough demos let you preview:
Advanced automations that scale work across thousands of pages
Prompt tracking, citation analysis, and content optimization for AI search
Enterprise reporting with customizable dashboards for different stakeholders
Competitive intelligence powered by Semrush’s market-leading database
Consolidate your stack and be first everywhere customers search, with Semrush Enterprise.
The fix is to start speaking the language the team wants to hear and to frame your work around why it matters to the company and to them personally. (see this post from a couple of weeks ago on how to do this. )
My favorite way of doing this is with a PRD, a product requirements document. Some organizations already use a PRD process, so this post should encourage you to adopt it. Other organizations don’t, and in that case, you can’t go wrong by professionalizing and streamlining your SEO tasks.
A PRD is what you use when you want something to actually get built. Product managers use to get engineers to ship features, and there is no reason you can’t use the exact same document structure to get SEO work done.
The second you start framing your SEO recommendations the way a product manager would frame a feature request, something shifts. Suddenly, you’re not the SEO person asking for SEO favors; you’re now a stakeholder presenting a scoped, prioritized project with a clear business case, and that is a completely different conversation to be in.
How to make an SEO PRD
Let me walk you through how to structure one from scratch, but if your organization already has a template, use that or copy mine. (Paid subscribers can download this template) A well-structured PRD for a mid-size SEO project can be long. It’s not a novel, but it’s not a Slack message either.
To be clear, I am not promoting the creation of a new PRD format; I want to adapt common PRD structures for SEO. SEO should not be inventing new processes that force others to adapt.
The first thing your PRD needs is a problem statement written in terms the business cares about, not in terms that SEO people care about. Nobody outside of SEO is going to get excited about “we have 47 pages with duplicate title tags.” That’s an SEO hygiene problem, but it’s not something engineers brag about in their standups. I’ve seen those standups. The engineers assigned to fix things like this tend to lower their voices when they mention it, because it feels like unglamorous work nobody really owns.
Instead, frame it as something worth caring about. “We’re leaving an estimated 12,000 organic visits per month on the table because pages that could be visible are competing against each other.” The same problem, but with a completely different framing. The problem statement opens the document, setting the tone for whether this is treated as a real project or a to-do list item someone glances at between meetings.
Have an owner and a date
After the problem statement, you’ll have a metadata section covering status, owner, last updated date, priority, and estimated dev effort. Don’t skip this part if it’s on the template. These are living documents, not essays. They get referenced, updated, and handed off, so that information actually matters.
After the necessary header information, it’s time to tell the story. I call this the opportunity, but call it whatever you want. This is where you explain the context, what it means, and the actual risk of not fixing it.
Engineers deserve the full picture; they’re going to care a lot more than if you just hand them a list of tasks. Tell them you ran a crawl using whatever tool you used, that you found X issues across Y pages, that these issues are affecting traffic because of Z reason, and that this ties back to a business goal the company already has. Tie it to something real, like revenue, a growth goal, or a competitor that’s outpacing you.
Requirements and work
After you set the stage, you move into the actual requirements section, where the structure of a PRD does most of the work. You break down every fix into a user story or a clear functional requirement, define what success looks like, and separate what is definitely required from what is nice to have.
If you haven’t written a user story before, the format is simple: “As a [person], I want [thing] so that [reason].” In SEO terms, that might look like: “As a site visitor arriving from search, I want each page to have a unique title tag so that search engines can correctly identify and rank the right page for each query.” It forces you to frame the fix in terms of function and outcome rather than just a technical task, which is exactly the framing that gets engineers to care. Engineers work in sprints, and they need to know what has to ship and what can be dropped if time runs short. If you don’t make that call, they’ll either guess and get it wrong or pull you into a meeting you both wish you weren’t in.
Acceptance criteria answer a simple question: how will we know when this is actually fixed? For an SEO project, that might mean specifying that, after implementation, you’ll pull a Search Console report showing improved average position for the affected pages within 90 days of the fix going live. The point is that there is a defined end state, not and it’s just a box to be checked. A project with acceptance criteria can not only be closed but also measured.
Implementation and dependencies
The technical notes section is where you get into implementation details, and how deep you go here depends on the complexity of the fix and your relationship with the dev team. For something simple like title tag updates, you might just need to link to a spreadsheet with the URL, current title, and recommended title for each page.
For something more complex, like fixing crawlability issues caused by how JavaScript is rendering content, you’ll need to go further. Which framework are they working in? Does this need to be handled server-side or in a CMS? What should the output look like in the HTML source? Are there edge cases or exceptions to account for? The more complex the fix, the more you need to think like the person who has to actually build it.
Your goal is not just to tell them there’s a problem and that they need to design a fix; you are telling them how to fix it. If you don’t know how to code, get ideas from your favorite AI chatbot, so even if they aren’t going to follow your recommendations, at least you have shown the right effort.
You always want to include a dependencies section. What does this fix require from other teams or systems before it can go live? Does it need a content review first? Does it require a staging environment test before production? Is it blocked by another sprint item? Dependencies are where projects go to die when they’re not documented, because someone gets halfway through implementation, realizes they’re waiting on something else, puts the whole thing down, and moves on. The PRD is then shared with those teams as well, so they can ask questions before the work is assigned to them.
Monitoring
You’ve written this whole document, gotten the ticket prioritized, the dev team actually ships it, and then what? If your PRD doesn’t include a section on what you’re going to monitor, how often, and what signals would indicate a problem versus expected volatility, you’re going to have a very uncomfortable conversation if something goes sideways after launch and nobody knows what to look for or who owns the response.
For most SEO fixes, your monitoring plan should cover which metrics you’re tracking, at what cadence, for how long, and your rollback criteria. The rollback criteria are important to define before you ship, because nobody wants to debate whether traffic has dropped enough to justify reverting a change in the middle of a crisis. Write it down beforehand. Something like: if organic traffic to the affected URL set drops more than 20% week over week in the two weeks following deployment, we will investigate and potentially revert. You are taking ownership rather than asking and forgetting.
The effort is worthwhile
The obvious objection is that all of this sounds like a lot of work for an SEO fix. Writing a full PRD for something small like updating a handful of meta descriptions is probably overkill. When anything requires significant engineering time, the PRD format pays for itself. The time you spend writing the document is nothing compared to the time you lose when a fix gets misunderstood, half-implemented, never tested, and then deprioritized again while you figure out what went wrong. Or the more likely scenario, it’s just an SEO ticket that is continuously ignored.
The strongest argument for adopting this process isn’t efficiency; it’s accountability on both sides. When a fix is implemented poorly because the requirements were vague, the SEO team usually takes the blame for the lack of results. If you have a PRD that clearly outlines the requirements and acceptance criteria, you have a paper trail that reads like every other team’s requests. If you want SEO to be more than an afterthought, give it the same rigor and effort that the org applies to every product request.
Drop comments or reply with other best practices you use to get things done.
[Sponsored by North Star Inbound ]
What happens when you combine best-in-class SEO with conversion optimization?
BigRentz’s traffic increased by 186% (85k), added 1950 conversions in 12 months.
Self Financial’s traffic increased by 50k/month, and added 685 new customers.
Lastly, Secure Data added 1968 phone calls.
North Star Inbound’s SEO strategies earn leads, conversions, and revenue..
Book a call for a free content audit and 10% off any engagement.
Intrigued? [Learn more here]