Should SEOs dictate technical solutions to developers, or simply expose the SEO problems they've identified?

Why is Google pushing this collaborative approach?

Tension between SEO and developers is a classic issue. Google regularly observes poorly executed SEO implementations imposed without consideration for technical architecture. The result? Broken sites, degraded performance, and ultimately... a terrible user experience.

By asking SEOs to present the problem rather than the solution, Splitt is trying to reframe the profession. The idea: you identify what's blocking indexation or ranking, developers figure out how to resolve it cleanly within their stack.

What's the concrete difference between presenting a problem and presenting a solution?

Imagine JavaScript-rendered content isn't indexing properly. "Imposed solution" approach: "You need to implement SSR with Next.js". "Exposed problem" approach: "Googlebot isn't seeing content generated by React, which impacts 40% of our strategic pages".

The nuance seems subtle — it isn't. In the first case, you're imposing a technical overhaul that may be unsuitable. In the second, you're opening the discussion: SSR, prerendering, static hydration... Developers choose the solution compatible with their infrastructure.

Does this recommendation fundamentally change how SEOs work?

No, but it redefines the scope of intervention. A good SEO has always been able to diagnose indexation, crawl, or structure issues. What changes is abandoning the illusion of controlling everything technically.

• Identify technical blockers with precision (server logs, Search Console, rendering tests)
• Document the business impact: unindexed pages, lost traffic, missed conversions
• Present the problem with data, not opinions
• Let developers propose solutions suited to their technical context
• Validate together that the solution actually resolves the initial SEO problem

Is this approach really new or just common sense being restated?

Let's be honest: it's common sense. But common sense that's consistently ignored by part of the profession who see themselves as system architects. I've seen catastrophic SEO recommendations imposed without any understanding of the underlying infrastructure.

The problem is that many SEOs can't diagnose a problem without immediately proposing their favorite solution. "Do SSR", "Go SPA", "Use prerendering"... Without even understanding the technical team's constraints.

In which cases doesn't this rule work?

When you're working with developers who have zero SEO culture. Some still view SEO as a baseless marketing constraint. In that case, presenting only the problem leads to... nothing. Or worse, a makeshift solution that creates more problems than it solves.

The other limitation: understaffed teams. When one developer already manages 15 projects, asking them to find the optimal solution for each SEO problem just adds cognitive load. Sometimes, proposing a direct technical lead speeds things up — as long as you remain open to other approaches.

What nuance should we add to this statement?

The boundary between "presenting a problem" and "guiding toward a solution" is blurry. A good SEO diagnosis often includes technical leads — without imposing them. "Googlebot isn't seeing client-side generated content; common solutions are SSR, prerendering, or static hydration, depending on your stack."

What really matters: collaborate rather than dictate. If your recommendation hits legitimate technical constraints, adapt. If you don't understand why a solution is rejected, ask questions instead of digging in your heels. [To verify]: does this approach work as well in organizations where SEO and dev never talk?

How do you effectively present an SEO problem to developers?

First, quantify the impact. "JavaScript is blocking Googlebot" won't move a tech team. "40% of our strategic pages aren't indexing, which represents 120,000 lost monthly visits" — that speaks volumes.

Then document with technical proof: Search Console screenshots, crawl logs, rendering tests from the URL inspection tool. Show the difference between what a browser sees and what Googlebot sees. Be factual, not alarmist.

What mistakes should you avoid in this collaborative approach?

Never present a problem without having verified your hypotheses. Too many SEOs blame JavaScript for everything without testing whether content is actually invisible to Google. Result: you lose all credibility when developers prove rendering works.

Also avoid obscure SEO jargon. "Crawl budget is saturated by parameterized facets" means nothing to anyone. Rephrase: "Googlebot wastes time crawling 80,000 product page variations that add no value, which slows down indexing of new content."

How do you validate that the technical solution actually solves the problem?

Test before deploying. If the proposed solution is prerendering, verify in staging that Googlebot actually sees full content. If it's a migration to SSR, check that response times remain acceptable.

Once in production, monitor indexation metrics: number of indexed pages, coverage rate in Search Console, organic traffic evolution on affected pages. If the problem persists, go back to diagnosis — without automatically blaming the technical implementation.

• Document every problem with quantified data (traffic impact, number of affected pages)
• Provide visual technical proof (Search Console screenshots, rendering comparisons)
• Present the problem in language developers understand, without SEO jargon
• Suggest solution paths without imposing them, remaining open to alternatives
• Test solutions in staging before production deployment
• Monitor indexation metrics post-implementation to validate effectiveness
• Maintain ongoing dialogue with the tech team to adjust if needed