Most SEO recommendations read like orders: change this title tag, add these links, fix that issue. The trouble is that a developer who gets an order can only follow it.

Connect on LinkedIn · Visit my site

SEOs usually know what the finished result should look like. So it's easy to slide from describing the result into describing exactly how to build it.

Gonzalez, writing for Search Engine Land, says working in product changed that habit. Knowing what needs to happen isn't the same as knowing the best way to build it inside a specific product.

Developers often know about reusable pieces, cleaner approaches, or ways to avoid technical debt. Technical debt just means shortcuts that make the next change harder. A request that's too specific can make the work slower to build and harder to maintain.

Before she scopes anything now, she asks four questions:

The line she draws is between a requirement and an implementation. Saying the links must be present in the rendered HTML is a requirement. Telling the developer to build one exact component one exact way is a prescription.

Rendered HTML is the version of the page a browser or crawler sees after scripts have run. That's the part you can't compromise on. How it gets there is the developer's call.

Gonzalez uses a small example: a module that shows three related internal links. The SEO version of that request is easy. Show three relevant links.

The product version asks more questions. Will you want more than three later? Does a blog post need different logic than a product page? What happens when there aren't three good results?

Can editors override the picks? Can another team reuse the module? Should clicks be tracked?

She's clear that none of this has to be in version one. An MVP, the smallest version worth shipping, is still the goal. The point is to avoid early choices that make the second version harder than it needs to be.

The question shifts from how to fix this right now to how to solve it now without boxing in whoever builds next.

Getting a change live, especially after a long wait, feels like the finish line. Gonzalez says it isn't.

After launch, she still checks whether people are using the feature, and whether they use it the way you expected. Then she asks if the original problem improved or if the change created a new one.

Her full workflow runs: problem, hypothesis, scope, build, launch, measure, learn, iterate. If you've run SEO tests, this will look familiar. Launch is when you finally see whether your hypothesis was right, not the end of the test.

I covered a related idea in September: deciding what counts as failure before a project starts.

Gonzalez puts it simply: "A tactic is not a problem statement." Adding FAQs is a tactic. So is building a separate page.

Start with what the user is struggling with, and why it matters. Then hand that over with the outcome you want and the must-haves, and leave room for the developer to propose the build.

Gonzalez's boss, James Nash, gave her three design questions worth borrowing:

Nash also has a rule worth remembering: if a user can mess something up, they will.

Write down what you expect to change and when you'll look. Then actually look, because a closed ticket only proves the work shipped.

One thing I'm thinking about: a lot of SEO work fails in the handoff, not in the idea. The recommendation was fine, but the person building it never heard why it mattered.

When a developer knows the problem, they can push back, suggest something better, or catch the edge case you missed. That's a better deal than getting exactly what you asked for.

Till next time,

Source