Silo-Busting: Integrating SEO into Dev and Design Workflows

This week, we're grateful to Liz Bowers who shares a practical playbook for embedding SEO into agile dev and design workflows, from the four Scrum ceremonies to a copy-paste ticket blueprint devs will actually action!

Every seasoned SEO has lived through some version of this nightmare: A company spends six months, dozens of meetings, and hundreds of thousands of dollars building a gorgeous, modern website. The branding teams are thrilled with the visuals, the product teams love the new feature blocks, and the developers are ready to push the repository live. Then, precisely one week before launch, someone asks, "Hey, did anyone check this for SEO?"

This is the origin of the "Afterthought Tax"—the compounding technical debt that occurs when organic search is treated as a final checklist item rather than a foundational requirement.

We all know that treating SEO as an afterthought comes at a cost, and it falls to us as SEOs to break down the silos in order to make stuff happen and get organic results. That’s what I’m going to cover in this article.

The Cost of Working in Isolation

In both agency and enterprise environments, the cost of working in silos manifests most dangerously during the planning of Information Architecture (IA). Decisions regarding site structure, folder hierarchies, and global navigation are often made in isolation by creative teams or IT departments. The prevailing mindset is frequently, "Let's just get it up there, and we can optimize the content later."

But you cannot easily "optimize later" a fundamentally broken site architecture.

When folder structures are decoupled from a logical content hierarchy, the damage is immediate and structural. Internal link equity is diluted, URL paths become nonsensical strings that confuse both users and crawlers, and critical contextual signals are lost.

Fixing these architectural flaws post-launch doesn't just mean rewriting a few meta tags; it means engineering costly, high-risk programmatic redirect maps, refactoring backend folder structures, and burning developer hours to fix problems that should have never existed in the first place.

A single pre-launch crawl of the staging environment—comparing the new IA against the live site's URL and link structure—would have surfaced most of this before a single line of code shipped to production. That check is cheap. The redirect map you have to build six months later is not.

The Product-Led Paradigm: SEO as an Umbrella Feature

To break this cycle, organizations must fundamentally shift how they view the role of search. In his book Product-Led SEO, Eli Schwartz argues that SEO should not be framed as a superficial marketing gimmick, but as a core product feature.

The challenge with this paradigm shift is that SEO rarely occupies a neat, isolated box on an org chart. Instead, it acts as an umbrella that spans across multiple business units. The SEO team doesn't govern the development roadmap, dictate the brand guidelines, or own the UI copy—yet search performance is completely dependent on all three.

Because of this, modern SEO must act as a strategic translator.

When we advocate for a clean directory structure, we aren't just chasing a Google algorithm update; we are translating the marketing team's branding goals into a logical, crawlable system that the development team can build with clean code. Search intent and user logic become the specifications for a successful digital product. When search strategy bridges the gap between creative execution and technical infrastructure from day one, the business builds permanent, compounding organic value.

Strategies for Enterprise and In-House Teams

In an in-house environment, leadership and marketing sign off on the strategy from a brand perspective, but that doesn’t complete the task, you have to also get through the engineering pipeline. You aren't just competing with other marketing ideas; you are competing for developer resources against core product features, security patches, and technical bug fixes.

If you try to hand a 50-page PDF technical audit to an enterprise engineering team, it will be immediately archived and forgotten. To succeed in-house, SEO must be completely integrated into the company's existing development framework.

Mastering Agile Ceremony Mechanics

The exact moment SEO recommendations go to die is usually within the company's meeting cadence. If you aren't in the room (or the digital workspace) when sprints are being shaped, your search initiatives will be pushed to the backlog indefinitely.

To prevent this, an in-house SEO must actively participate across the four classic Scrum lifecycle ceremonies:

1. Backlog Refinement: This is where you introduce SEO initiatives early. Don't wait for sprint planning to dump a massive site architecture change on the team. Use refinement sessions to talk through technical prerequisites with lead engineers, answer their initial edge-case questions, and ensure the ticket is fully understood and "ready for dev" before it ever gets scheduled.
2. Sprint Planning: Treat this as your pitch meeting. You are sitting alongside product managers, defending why an SEO user story deserves a spot in the upcoming two-week cycle over a minor UI tweak. Ground your argument in business metrics, show the technical risk of delaying the work, and secure a firm commitment of story points for that sprint.
3. The Daily Standup: Spend a few minutes checking the board. Monitor active SEO tickets to see if they're moving from "To Do" to "In Progress." If a developer mentions an infrastructure blocker or suggests a shortcut that could accidentally compromise indexability, you are right there to step in, clarify, and keep the deployment safe.
4. Sprint Review & Retrospective: Use this time to celebrate wins and analyze bottlenecks. Show the engineering team the tangible impact of the code they just shipped—like a drop in crawl errors or an increase in rendering speed. If an SEO ticket got dropped or delayed, use the retrospective to figure out why the process broke down without pointing fingers.

Enterprise Proof in Action

This level of agile integration is how sophisticated engineering organizations scale organic growth.

Etsy, for instance, treats SEO as a data-driven engineering discipline rather than a bolt-on: its engineering team has documented running controlled experiments on page elements like title tags, measuring the causal impact on search-driven traffic the same way they'd test any other product feature. That's the mindset shift worth arguing for—search performance treated as something you instrument and test, not something you audit after the fact.

You don't need Etsy's scale to apply the principle. Any team that wires SEO checks into its existing experimentation or CI process, instead of running them as a separate audit cycle, gets the same benefit: problems surface while they're still cheap to fix.

The In-House Win: A Multi-National Domain Migration

I learned the power of this structured, agile approach firsthand while working in-house, leading a massive multi-site technical domain migration for a multi-national brand. The project required migrating legacy .html URL structures over to a modern slug architecture across several international web properties.

On an enterprise scale, a shift of this magnitude involves hundreds of thousands of URLs and millions of dollars in recurring organic revenue. If we had handled this as a traditional marketing handoff, the risk of miscommunication and broken redirects would have been catastrophic.

Instead, we embedded the SEO requirements directly into the engineering department's sprint cycles. We broke down the massive migration blueprint into bite-sized user stories, mapped out the exact URL folder redirections inside the developer's sprint tickets, and participated in every refinement session to clear up technical questions. We also ran automated crawls against staging before every release to catch broken redirects and orphaned pages before they ever reached production.

Because the development team was part of the planning process from day one, we launched the new slug architecture on schedule—with zero measurable loss in organic sessions in the 30 days following launch, and no crawl-error spike in the post-launch audits. That's the proof point that matters to leadership: the migration protected the brand's global search equity because the technical work was planned as engineering, not bolted on as marketing.

SOPs and SEO "Champions"

You cannot scale enterprise SEO by trying to be in every single meeting or review every single line of code yourself. True scale comes from creating centralized, easily accessible Standard Operating Procedures (SOPs) that live where developers already work (such as internal wikis).

More importantly, you need to cultivate organic SEO "champions" within the engineering and design teams. Find the front-end developer who is naturally interested in web performance, or the UX designer who cares deeply about accessibility. Educate them, share data wins with them, and empower them to protect technical search health within their own teams. When dev teams start peer-reviewing code for indexability guidelines before you even see it, you've successfully built a self-sustaining culture of collaboration.

Workflow Template: Selling SEO to Leadership and Dev Teams

Getting cross-departmental buy-in for technical SEO is about aligning your goals with theirs. To get your tickets prioritized, you need to speak the language of business metrics to leadership, and the language of structured requirements to engineering.

The Business Case

Before a developer ever opens a ticket, a Product Manager or Director needs to approve the engineering hours. To justify dedicating a sprint to systemic or speculative search updates, move away from vague promises of "more traffic." Instead, speak in terms of revenue, user acquisition, and potential Return on Investment (ROI).

In Product-Led SEO, Eli Schwartz introduces the concept of an "Avatar Quest"—a targeted, hypothesis-driven product experiment designed to discover how a specific user segment searches for and interacts with your product.

When pitching a major structural or technical pivot to leadership, frame it as an intentional experiment with a calculable downside and a high-upside financial return.

Calculate the baseline value of the traffic you are currently losing to architectural inefficiencies. Show leadership that if a 10-hour development task resolves a rendering issue that blocks a core money-making directory, the potential lift in conversion rate yields an ROI that far outweighs the cost of those engineering hours.

When technical health is tied directly to the balance sheet, the approval process becomes a math problem, not a debate.

Editor’s Note: Learn more clever ways to express SEO value in financial terms in our Website Migrations Training Course.

Translating SEO into Dev Speak

Once leadership greenlights the resource allocation, the initiative moves into the engineering pipeline. This is where your strategy must be translated into the exact format developers use daily.

The most effective way to eliminate friction is to hand them a High-Level SEO Ticket Blueprint (below). By breaking your technical search requirements down into a standardized, agile user story with explicit acceptance criteria, you remove all ambiguity.

Here is the exact template you can copy, paste, and adapt directly into Jira, Azure DevOps, or your team's project management tool of choice:

The High-Level SEO Ticket Blueprint

a. The User Story (The "Why")

This establishes who wants the change, what the change is, and what business metric or SEO goal it drives. It uses a standard three-part agile format:

• As a: [Role, e.g., SEO Specialist / Product Owner]
• I want to: [Clear description of the feature or technical change]
• So that: [The business value, e.g., improve crawl efficiency, boost mobile rankings, fix indexing issues]

b. Acceptance Criteria (The "What")

This is a bulleted list of strict rules that define when the ticket is officially "done." To keep it simple but clear for developers, break it down by the standard path, messy variations, and exclusions.

• The Happy Path (Standard Behavior): What should happen under normal, ideal conditions?
• The Variations & Edge Cases: How should the system handle messy situations? (e.g., What happens on mobile? What happens if a URL has parameters? What happens if an image is missing?)
• The Exclusions (What NOT to do): Are there specific pages, directories, or environments where this rule should never apply?

c. Verification & QA (The "Proof")

A quick sentence or two explaining exactly how a developer or QA tester can verify that the change is working before it goes live.

Sizing, Prioritization, and the QA Safety Net

With your ticket cleanly formatted, you can confidently walk into a backlog refinement session to assign story points with product managers and lead engineers. Breaking a massive site audit down into these bite-sized, isolated user stories prevents developer fatigue and significantly reduces pushback.

The final gate is the QA and Launch phase, where the ticket's acceptance criteria are actually put to the test.

Instead of manually checking individual URLs or risking production errors, this staging phase relies on running automated crawler audits against the test environment. By utilizing a technical crawler like Sitebulb to audit staging servers and compare pre- and post-launch data sets, you can programmatically validate that rewrite rules are firing correctly, canonical chains aren't breaking, and JavaScript rendering pipelines match expectations before code is merged.

This transforms the "How to Verify" section of your ticket from a manual guessing game into an automated, quantifiable check.

Building a Culture of Collaboration

At its core, silo-busting isn't about mastering project management software or forcing other teams to memorize search engine documentation. It's about building a culture of mutual respect, open communication, and shared goals across historically isolated departments.

When you stop treating SEO as a proprietary marketing secret and start embedding it as a transparent, data-backed part of the product, you speak the native languages of product, design, and engineering.

For professional SEOs chipping away at deeply ingrained corporate silos, the shift won't happen overnight. But by consistently leading with user data, respecting creative boundaries, and delivering flawless, developer-ready sprint tickets, you earn your seat at the table. You stop chasing the aftermath of web builds—and start architecting organic growth from the foundation up.