Should SEO experts really be involved from the technical design phase?

Why does Google insist on this early collaboration?

Martin Splitt's statement reflects a ground reality: too many web projects deploy features before considering the SEO question. Result? Poorly structured URLs, non-crawlable content, missing canonical tags, or problematic redirects.

The problem is that fixing after the fact often involves heavy refactoring, risky URL migrations, or worse — accepting makeshift solutions that will penalize organic visibility for months. Involving SEO upstream allows you to anticipate these pitfalls and integrate indexing constraints right into the architecture.

What exactly is meant by "design phase"?

Splitt mentions three key stages: the roadmap (strategic planning of developments), the design doc (detailed technical specifications), and the PRD (Product Requirements Document).

Concretely? The SEO expert must be consulted before code is written. Not after the sprint, not during testing — during the phase when architectural decisions are still flexible.

Which pages are covered by this recommendation?

Any page intended to be indexable — so visible in the SERPs. This includes product pages, blog articles, category pages, landing pages, but also features like pagination, filters, internal search if it generates public URLs.

On the other hand, purely transactional interfaces (checkout flow, member area) generally escape this constraint, unless they expose publicly crawlable content.

• SEO involvement must occur before code is written, not after deployment
• This concerns all pages intended for organic indexing
• Post-deployment fixes cost 10 times more in time and risk
• The roadmap, design doc, and PRD are the three strategic entry points

Does this recommendation reflect organizational reality?

Let's be honest: in the majority of structures, SEO still intervenes too late. Product and dev teams move forward without consulting organic experts, then discover — often after a post-launch audit — that the site has crawl issues, duplication problems, or structural flaws.

This gap is explained by several factors: lack of SEO awareness on the product side, absence of formalized process, or simple business prioritization that pushes to ship fast. Result? Hasty migrations, preventable traffic losses, emergency fixes that destabilize the roadmap.

What are the limitations of this statement?

Splitt doesn't specify how to concretely integrate SEO into these phases. Should you add a systematic SEO reviewer to design docs? Create a SEO requirements checklist for each PRD? [To verify] — Google remains vague on the operational format.

Another blind spot: not all SEO experts have the technical skills to evaluate a backend-oriented design doc or complex product roadmap. You need a hybrid profile — technical SEO + product/dev culture — and these profiles are rare.

In which contexts is this approach most critical?

High-volume page sites — e-commerce, media, marketplaces — are most affected. In these environments, an architecture error propagates to thousands of URLs and can destroy months of rankings.

Conversely, for a 10-page brochure site or a SaaS without a blog, the stakes are lower. Coordination effort should be proportional to actual SEO risk.

How to concretely integrate SEO into these design phases?

First step: formalize a mandatory SEO review process for any project affecting indexable pages. This involves adding a SEO gate to the product cycle, with explicit validation before development starts.

Next, document standard SEO requirements to be systematically integrated: URL structure, canonical tag management, pagination, breadcrumbs, redirect rules, meta robots. These specs become non-negotiable prerequisites, just like security or accessibility.

What tools or frameworks facilitate this collaboration?

Some teams use a SEO Design Checklist integrated directly into Jira, Notion, or Confluence. Each ticket related to an indexable feature automatically triggers a SEO review.

Another approach: organize co-design workshops between SEO, product managers, and lead dev at the start of the sprint. These sessions allow you to anticipate technical constraints and settle trade-offs before implementation.

Which errors must be absolutely avoided?

Don't fall into the "SEO police" trap that blocks everything without proposing alternatives. The SEO expert must be a force for proposals, not simply a censor listing prohibitions.

Another pitfall: intervening too late on the pretext that you weren't "invited". You must impose yourself in the product process, even if it means doing internal lobbying to get a seat at the decision-making table.

• Implement a mandatory SEO gate before any development of indexable features
• Document standard SEO requirements that can be reused (URL structure, canonicals, pagination…)
• Integrate a SEO reviewer in design docs and PRD via the project management tool
• Organize SEO/product/dev co-design workshops at the start of each sprint
• Train product managers on basic SEO issues so they anticipate needs
• Create a library of validated SEO patterns to speed up trade-off decisions