Why should SEO be involved from the technical architecture phase of a web project?

Why does Google emphasize the early involvement of SEOs in projects?

The answer lies in a harsh reality: architectural mistakes cost ten times more to fix later. A website developed without SEO constraints may end up with a chaotic URL structure, poorly configured client-side rendering, or worse—an architecture that makes indexing random.

When Martin Splitt talks about architectural decision phases, he refers to structural choices: JavaScript framework, rendering strategy (SSR, CSR, SSG), facet management in e-commerce, pagination, canonicalization. These decisions made in technical meetings without SEO at the table can sabotage months of editorial work.

What does it really mean to 'not wait until everything is developed'?

The classic mistake: SEO comes in after the development sprint, discovers a Fully Client-Side Single Page Application, with no prerendering or intermediate server. The result? Googlebot crawls either empty pages or partial content. Redoing server-side rendering afterward involves a partial redesign—time, budget, friction.

Getting involved from the start means being present when choosing Next.js vs Nuxt vs a custom headless CMS. It's about being able to say, 'be careful, this choice of dynamic routing will generate URLs with non-canonical parameters.' It’s validating that the e-commerce faceting system indeed includes management of canonical tags and smart noindex directives.

Why does Google link SEO, UX, accessibility, and design in this statement?

Because these four disciplines share a common goal: navigability and content understanding. An accessible architecture facilitates crawling. A clear UX improves behavioral signals. A coherent design structures information logically for both machines and humans.

Google wants to break the notion that SEO is just a patchwork layer added at the end of a project. If developers integrate from the start that performance, accessibility, and indexability are constraints on par with security, the sites are better designed. No magic: just a more mature product approach.

• Intervene early in technical design phases to validate architectural choices (framework, rendering, URL, taxonomy)
• Participate in user stories and wireframes to ensure the information structure is logical for machines
• Document SEO constraints in functional specifications, not in an annex document that no one reads
• Establish SEO checkpoints at every critical stage of the project (architecture, design, development, pre-production, launch)
• Train technical teams on the fundamentals of crawling, rendering, and indexing so they understand the stakes

Is this statement consistent with practices observed in the field?

Yes, and it's even a sentiment shared by the majority of technical SEOs in agencies or in-house. Projects where SEO arrives after technical choices systematically turn into rear-guard battles: negotiating fixes, justifying additional budgets, losing rankings because the migration went poorly.

The problem is that company culture doesn’t always align. In many organizations, SEO remains a peripheral function, consulted out of courtesy but rarely involved in strategic decisions. Developers receive product specs, design constraints, security requirements—but SEO? Optional. And that’s where the issues arise.

What nuances should be added to this Google recommendation?

First nuance: not all projects warrant heavy SEO involvement from the design phase. A three-page showcase website for a local SME doesn't need an architectural audit. However, an e-commerce site with 50,000 references, a media site with dynamic content generation, or a multi-vendor marketplace—there, early involvement is critical.

Second nuance: telling developers to 'take SEO seriously' without providing concrete training is wishful thinking. A front-end developer who doesn’t understand the difference between client-side and server-side rendering cannot make good SEO decisions, even with the best intentions. Training, documentation, and clear technical guidelines are required. [To be verified]: Google never specifies how to measure if this collaboration is actually working.

In what cases does this rule not apply strictly?

On projects with low organic stakes, where most traffic comes from direct, paid, or email sources. Typically: a private client area, a SaaS business application with 100% outbound acquisition, a temporary event site. There's no need to mobilize a senior SEO during the design phase.

Another case: ultra-mature product teams that have already internalized SEO constraints into their processes. Some tech companies have developers who know rendering, crawl budget, and hreflang tags better than some junior SEOs. In this context, early intervention happens naturally—no need for a reminder.

What concrete steps should be taken to get involved from the architectural phase?

The first step: secure a seat at the table for technical decision-making. This requires internal political negotiation. SEO must demonstrate that it adds strategic value, not just recommendations for meta descriptions. Participate in product rituals, architecture meetings, sprint reviews.

Next, prepare clear and actionable technical documentation for developers. Not an 80-page PDF that no one will read. SEO-oriented user stories: 'As Googlebot, I need to be able to crawl all product pages without infinite loops.' Validated architecture diagrams. Commented code examples for frequent use cases (pagination, faceting, JavaScript).

What mistakes should be avoided in this collaborative process?

Mistake number one: arriving with an unyielding list of non-negotiable requirements. Developers have their own constraints (deadlines, technical debt, framework-imposed choices). An SEO that shows up and declares 'everything must be redone in SSR' without understanding the technical implications will be ejected from the discussion.

Another mistake: confusing early involvement with micromanagement. The role of SEO is not to validate every commit or review every line of code. It is to ensure that structural choices are compatible with indexing and ranking. Afterward, developers should be trusted to execute correctly.

How can we verify that this collaboration is actually working?

A simple indicator: the number of major SEO corrections detected in pre-production. If each UAT audit reveals structural errors (missing canonicals, non-crawlable content, redirect chains), it indicates that early involvement has failed. Conversely, if audits only bring up minor adjustments, it means the collaborative process is functioning.

Another metric: the resolution time for SEO bugs. In a mature organization, a detected crawl bug is fixed in the next sprint. In an immature organization, it requires negotiation, escalation, justification—and the fix comes three months later. The speed of reaction reflects the actual level of integration of SEO into the processes.

• Participate in scoping and technical architecture meetings from the project's design phase
• Document SEO constraints in user stories and functional specifications
• Train developers on the fundamentals of crawling, rendering, and indexing
• Create clear and illustrated technical guidelines (code examples, validated architecture diagrams)
• Implement SEO checkpoints at every critical stage of the project (wireframes, mockups, development, testing)
• Systematically audit pre-production to validate that architectural choices work effectively