SEO is a product feature in Technical SEO for Developers

For most of my career, I've watched teams treat SEO as an afterthought—something you bolt on when launch is over or when marketing complains about rankings. The reality I've learned at every scale, from early-stage startups to platforms handling millions of requests, is that SEO is a product feature. It deserves the same rigor, planning, and ownership as performance optimization or security. When you build discoverability into your system from day one, you stop fighting technical debt and start shipping features that users can actually find.

Why developers must own SEO like they own uptime

Here's what changed my thinking: I was reviewing PRs on an e-commerce platform, and we shipped a new product listing page. The code was clean. Performance was good. But the page had zero semantic HTML, no meta tags, no internal linking strategy. We discovered the issue six weeks later when organic traffic tanked. The engineering cost to fix it retroactively—refactoring templates, rebuilding data flows, migrating content—was 10x the cost of getting it right upfront.

SEO fails when developers view it as external to their domain. But if you're building the URL structure, you're making an SEO decision. If you're choosing client-side rendering, you're making an SEO decision. If you're not tagging your content, you're making an SEO decision—just a bad one. The only way to win is to treat discoverability the same way you treat performance budgets or OWASP compliance: as a non-negotiable quality bar.

This doesn't mean you become an SEO specialist. It means you become SEO-literate enough to catch issues in design reviews and pull requests, just like you'd catch a missing rate limit or a SQL injection.

Include SEO requirements in tickets

The first place SEO dies is in the planning phase. A ticket lands in your backlog: "Build category page." No mention of canonical tags, no acceptance criteria around metadata, no discussion of pagination strategy. By the time development starts, it's too late to influence the architecture.

I started adding an "SEO checklist" section to every ticket template. It lives alongside performance and security considerations. Here's what we include:

• URL structure: Is this URL permanent, semantic, and cacheable? Does it follow your site's hierarchy?
• Metadata: Do we need <title>, <meta name="description">, <meta name="robots">, or JSON-LD schema?
• Heading hierarchy: Will there be an <h1>? One per page. Are subheadings properly nested?
• Rendering: Is this server-rendered or client-rendered? Client-side needs prerendering or a headless service for crawlers.
• Internal linking: What pages should link to this? Should this link outward?
• Mobile experience: Does this layout work on small screens? Google's crawlers now prefer mobile-first indexing.

Real example from a SaaS platform I worked on: we were building a "team members" admin page. Marketing wasn't on the ticket. We didn't mention SEO. A junior developer made it client-rendered with useEffect to fetch the list. When a search engine crawler hit it, it got a blank page and moved on. We fixed it by prerendering critical pages and adding a <noscript> fallback, but we could have avoided the work entirely by asking the right questions in the ticket.

Your ticket template should say something like:

"This endpoint returns data at /api/products?category=electronics. SEO requirement: render this as /electronics/products with server-side title and description. Include <script type="application/ld+json"> for product schema. Do not paginate beyond page 3 (rel=nofollow page 4+). Acceptance: pass lighthouse --view=mobile and validate schema with Google's tool."

When SEO is in the ticket, developers know it's real work, not optional polish.

Review SEO impact in pull requests

Code review is your enforcement mechanism. If your team doesn't check SEO in PRs, your tickets don't matter. I've seen changes land that broke canonical tags, removed heading structure, or introduced redirect chains—all missed because reviewers weren't trained to look for them.

Add an SEO section to your PR template:

• Does this change affect URL structure or redirects?
• Are there changes to rendered HTML (headings, metadata, schema)?
• Does this introduce client-side rendering for indexable content?
• Are there performance implications? (Slow pages rank worse.)
• Should marketing or content ops review this?

Concretely: I reviewed a PR that refactored a blog post rendering layer. The developer moved from server-side rendering to client-side React. The code was solid, and the performance was fine on fast connections. But the SEO impact was severe—search engines would no longer index the title, description, or body text immediately. I left a comment: "This needs prerendering or static generation. Blog posts can't be CSR-only. Let's pair with you on this." We shipped a solution using Next.js's getStaticProps in an hour. Without that review gate, the blog would have become invisible to search engines.

Here's a checklist I put in every repo's PR template:

## SEO Review Checklist

- [ ] No new URLs without canonical tags (or they inherit from a parent)
- [ ] <code><h1></code> exists (exactly one) if this is a content page
- [ ] <code><title></code> and <code><meta name="description"></code> present or inherited
- [ ] New API endpoints aren't breaking pagination or filtering SEO
- [ ] Redirects are permanent (301) unless temporary (302), with reason documented
- [ ] Mobile-friendly check passed (<code>lighthouse --mobile</code> or similar)
- [ ] Schema markup added if applicable (Product, Article, BreadcrumbList, etc.)
- [ ] <code>/robots.txt</code> or <code><meta name="robots"></code> reviewed if indexability changed

Your reviewers don't need to be SEO experts. They just need to know what to look for and escalate when something looks off.

Own SEO metrics with marketing

The biggest mistake I made early on was treating SEO as someone else's metric. Engineering shipped features. Marketing reported rankings. Never the twain shall meet. Then a traffic drop hit, blame flew around, and nobody had the data to explain what happened.

I flipped the model: your team should own organic traffic and keyword rankings for the pages you build, the same way DevOps owns uptime. You don't need to be the marketing expert. You just need to be in the room when targets are set and when results are reviewed.

This means:

• Weekly standup slot: Share one metric. Bounce rate on new product pages up? Indexation coverage dropped? That's your signal to dig in.
• Shared dashboard: Google Search Console data, Core Web Vitals, indexation status. Make it visible to everyone, not siloed in a marketing tool.
• Post-mortems for traffic drops: If organic traffic falls 20%, that's a "SEV-2" incident. Treat it like you'd treat a production outage. Often the root cause is technical—a redirect loop, accidental noindex tag, or broken site structure.
• Quarterly planning: When marketing says "we want to rank for X keywords," engineering should estimate the work. URL structure changes, rendering architecture, internal linking—these take time and deserve estimation.

Real example: a travel platform I worked on saw organic traffic decline 15% overnight. Marketing panicked. I pulled logs and Google Search Console data. We'd shipped a code change that added Vary: Accept-Encoding to cache headers without including all the necessary vary values. Google's crawler hit inconsistent responses, and half the pages got marked as duplicates. We fixed it in 30 minutes—but we caught it because I was reading the same metrics as marketing. If we'd been in separate silos, it would have taken a week to diagnose.

Create a simple shared metric stack:

These numbers should live in your Slack or ops channel, not in a silo.

Build tools so content teams can self-serve

Here's what I learned the hard way: if content teams have to ask engineering every time they want to publish a page or change a title, your SEO will stagnate. They'll work around you. They'll ask for features you can't prioritize. You'll become a bottleneck.

The solution is tooling. Build internal tools that let content teams manage SEO without touching code.

I've built three that always pay for themselves:

1. Metadata management UI: A dashboard where content teams can edit page titles, descriptions, and schema markup. This ties into your rendering layer—so when they save, the page automatically renders with the new metadata. No deploy needed. For Next.js, this might be a simple admin UI that writes to a database, which your pages query at render time. For a travel site, we built a form where content could edit destination page titles and descriptions, and it lived in a CMS database that the Next.js rendering layer pulled from.
2. SEO health checker: A tool that audits pages for common issues: missing <h1>, duplicate titles, broken internal links, slow load times. Content teams run it before publishing. Engineers see aggregate data. We built a simple Next.js API endpoint that took a URL, crawled it headless, and returned scores for title/description/headings/schema/performance. Integrated it into our CMS publish flow as a pre-flight check.
3. Redirect manager: A UI for creating and monitoring redirects. This prevents the "someone created a 404" disaster and lets you track whether old URLs are still getting traffic. For an e-commerce platform, we built a form where the merchandising team could request redirects (old product URL to new one), and it auto-generated the redirect rule and logged it. We surfaced redirect chains and unnecessary hops.

The investment is maybe 5-10 engineering days. The return is that content teams can ship independently, and you spend your time on architecture instead of answering "can you change the page title?"

Common mistakes

• Treating SEO as one person's job: If one marketer owns all SEO decisions, it won't scale. Engineers make structural choices that affect SEO every day. They need context and accountability.
• Optimizing for rankings before fixing the basics: Lots of teams chase fancy schema markup and internal linking strategies while their site is still client-rendered or has broken pagination. Fix crawlability and indexation first. Optimization comes later.
• Not measuring what you change: You ship a new rendering strategy or refactor your URL structure. How do you know it worked? If you're not tracking organic traffic and indexation before and after, you have no data. Measure the delta.
• Forgetting about Core Web Vitals: Google ranks faster sites higher. If you're shipping something that hurts Largest Contentful Paint or Cumulative Layout Shift, you're hurting SEO even if the HTML is perfect. Performance and SEO are inseparable.
• Siloing SEO knowledge: If only one engineer understands your site's SEO setup, you're fragile. Document it. Pair on it. Train the team.

Key takeaways

• SEO is a product feature, not an afterthought. Include it in tickets, review it in PRs, and own its metrics like you own performance or security.
• Add SEO acceptance criteria to tickets—URL structure, metadata, rendering strategy, mobile UX, schema markup. Be specific.
• Make PR review a gate for SEO changes. Train reviewers to spot canonical tag issues, broken heading hierarchies, client-side rendering of indexable content, and redirects.
• Share SEO metrics with marketing. Organic traffic, indexation, and crawl errors should be visible to the whole team. Investigate drops like you'd investigate outages.
• Build internal tools so content teams can manage metadata, check page health, and create redirects without asking engineering for every change. This unblocks them and reduces toil.
• Treat technical SEO improvements (fast rendering, proper markup, mobile UX) the same as any other product investment. Estimate the work, track the impact, and celebrate the wins.