Do web developers do SEO?

Do web developers do SEO? It’s a short question with a layered answer. At a surface level, developers implement the technical work that makes pages visible to search engines. At the same time, SEO specialists set strategy, keywords, and editorial priorities. When teams collaborate well, visibility and user experience both improve. When they don’t, important fixes stall and pages go unseen.

Think of a website like a house: SEO strategists design the rooms and pick what’s placed inside. Developers lay the foundation, run the wiring, and make sure the doors open. That means technical SEO sits squarely in the engineering realm when a change requires code, server configuration, or deployment shifts. Still, strategy, keywords and content structure remain an SEO responsibility. The best outcomes come when both sides share responsibility for the same measurable goals.

Who owns technical SEO and why it matters

Think of a website like a house: SEO strategists design the rooms and pick what’s placed inside. Developers lay the foundation, run the wiring, and make sure the doors open. That means technical SEO sits squarely in the engineering realm when a change requires code, server configuration, or deployment shifts. Still, strategy, keywords and content structure remain an SEO responsibility. The best outcomes come when both sides share responsibility for the same measurable goals.

What developers typically own

Developers usually handle site performance, Core Web Vitals, crawlability and indexability, implementation of structured data, canonical tags, redirects, HTTPS configuration and mobile compatibility. These are things that require code changes, server settings or CI pipeline updates. Because of that, engineering tends to be accountable for the technical implementation.

What SEOs typically own

SEO teams lead keyword strategy, content planning, internal linking, outreach, and editorial calendars. They also define acceptance criteria: which queries and pages matter most, how to measure success, and what the expected outcome of a technical change should be.

Where work overlaps

Overlap areas-like page speed, structured data testing, JavaScript rendering and measurement-benefit from a blended approach. Tools such as Lighthouse and WebPageTest matter to both developers and SEO specialists because page speed influences user behavior and discoverability. Structured data often needs an SEO definition of intent and a developer implementation in JSON-LD. The best teams pair those skills with shared acceptance criteria and CI checks. For a hands-on developer checklist, see the developer SEO checklist.

Why Core Web Vitals still matter

Core Web Vitals-largest contentful paint (LCP), cumulative layout shift (CLS), and first input delay (FID) - remain practical ways to measure user-facing performance. Treat them as user experience goals rather than isolated numbers. LCP measures how fast the main content appears; CLS measures visual stability; FID measures interactivity delays. Translate these into ticket-level acceptance criteria and they become actionable.

One real example: a team replaced a static page hero with a large image carousel. Designers loved it. Lighthouse flagged a poor LCP. The team lazy-loaded images, but JavaScript still blocked the main thread. The compromise was to show a static hero image for initial load and defer the carousel script until after the largest contentful paint. The result: improved Lighthouse scores and fewer mobile bounces. The lesson? Small compromises can serve both experience and discovery.

One real example: a team replaced a static page hero with a large image carousel. Designers loved it. Lighthouse flagged a poor LCP. The team lazy-loaded images, but JavaScript still blocked the main thread. The compromise was to show a static hero image for initial load and defer the carousel script until after the largest contentful paint. The result: improved Lighthouse scores and fewer mobile bounces. The lesson? Small compromises can serve both experience and discovery. A clear logo helps users orient quickly.

Structured data: who writes it and who tests it

Structured data is a classic shared responsibility. SEO teams decide which schema types matter-Article, Product, FAQ, Event-and which fields to include. Developers embed the JSON-LD and place it inside templates or component renderers. Implementation doesn’t guarantee rich results, but it clarifies content for search engines and can unlock enhanced features when done correctly.

Practical approach: keep canonical examples of markup in a shared document. Create a small unit test that asserts required JSON-LD fields exist-name, price, availability for product pages, for example. Add Rich Results test runs into CI so that broken or missing markup fails a build before it reaches production.

JavaScript rendering: SSR vs CSR vs hybrid

Modern apps increasingly rely on JavaScript. That creates a choice between server-side rendering (SSR), client-side rendering (CSR), and hybrid models. Client-rendered content means search engines must run JavaScript to see it. That can work, but it introduces uncertainty about indexing and render timing.

Developers usually pick a rendering strategy. SEOs care about crawlability, presence of metadata in server responses, and canonical preservation. A pragmatic compromise many teams use: pre-render or statically generate discovery-critical pages (home, top category, top content), and continue CSR for less-important routes. Instrument index coverage and monitor Search Console-like data to catch regressions quickly. For practical strategies aimed at developers, see Technical SEO strategies for web developers.

Deployment workflows and prioritization

Many delays happen because SEO tickets lack clear acceptance criteria or fall into long engineering backlogs. Change the input: instead of “make pages faster,” provide a testable goal like “reduce median LCP on mobile homepages to under 2.5s as measured by Lighthouse in our stable cron job; verify no regression in index coverage.” That makes the request scannable and schedulable for engineers.

A CI pipeline that runs Lighthouse CI, checks canonical tags, validates robots.txt and hreflang, and runs a Rich Results test cuts feedback loops. Pair that automation with a light RACI model-who’s Responsible, Accountable, Consulted and Informed-and many deployment arguments disappear.

Acceptance criteria that actually work

Good acceptance criteria are short and measurable. Examples:

Performance ticket: After deployment, 75% of staging page loads should have LCP < 2.5s on a 3G throttle and desktop CPU slowdown; Lighthouse performance score must not drop below 90; CLS < 0.1 in 99% of loads. Add a Lighthouse CI job to enforce these checks.

Structured data ticket: Product pages must include JSON-LD with name, description, price, currency, availability and image. Run the Rich Results test in CI and fail the build if required fields are missing.

Checklist teams can use before merging

Make this a read-before-merge paragraph every engineer skims:

Confirm robots.txt allows indexing of public pages; ensure sitemap updates for new routes; verify canonical tags are present and correct; check hreflang for multilingual sites; validate redirect behavior (301 vs 302); confirm images and assets are compressed and lazy-loaded appropriately; verify caching headers and CDN rules; include structured data for content types and run the Rich Results test; run Lighthouse CI against a staging instance; and confirm mobile viewport and touch targets behave correctly.

How much SEO ownership should developers keep?

There’s no single right answer. During launches or architecture shifts, engineers often own monitoring setup: Lighthouse CI, WebPageTest dashboards, Core Web Vitals monitoring and schema tests. After stability, SEOs can take over day-to-day monitoring and prioritization, with engineering on call for code-level fixes.

Common practice: developers keep CI checks and alerts; SEOs own dashboards, interpretation and prioritization. This keeps engineers from being the default triage queue while ensuring technical problems get fixed by the people who can change code.

Single-page applications: pragmatic patterns

SPAs are great for UX but add complexity for indexing. The workable pattern is selective pre-rendering: identify discovery-critical pages and pre-render them. Use static generation, server-side pre-rendering, or embed critical content in server responses for these pages. For less critical routes, CSR is fine.

Instrument indexing coverage and monitor logs from a bot’s perspective. If indexing drops after a release, reproduce the smallest case and check server responses, rendered DOM, and bot logs.

Measuring impact without chasing noise

SEO measurement is noisy. Start with a clear hypothesis and a narrow metric. If you change canonical emission, your hypothesis might be that index coverage for category pages improves. Track the number of valid indexed category pages and ratio of indexed to discovered pages over a reasonable window, for example six weeks.

A/B tests are possible at scale: route a fraction of traffic to pre-rendered HTML and measure indexing and engagement. It’s complex but can settle debates where theory conflicts with data.

Practical monitoring tips

Use a combination of Search Console data (or equivalent), server logs, and client-side performance monitoring. Set alert thresholds for sudden drops in index coverage or spikes in crawl errors. Maintain a small set of prioritized pages and watch them closely after deployments. For developer-focused monitoring advice, see this must-have SEO checklist.

Rituals that cut meetings and reduce friction

Try a short weekly engineering-SEO sync with three items: urgent blocks, upcoming launches with SEO impact, and CI failures related to SEO checks. Keep SEO tickets precise and include acceptance criteria. Add engineers as reviewers on SEO docs that require code changes. Treat experiments as data, not ego battles.

If you need a discreet pair of expert eyes on a migration or a CI integration, consider a short review from Orvus Ltd. Their audits focus on process and acceptance criteria rather than long engagements - a compact review can clarify responsibilities and speed a migration. Learn more from their services page.

Common pitfalls and how teams solved them

Frequent mistakes include missing acceptance criteria, treating SEO requests as low priority, and failing to instrument results. Teams that solved these issues did three things: they required acceptance criteria on requests, added SEO checks to CI, and agreed on a lightweight RACI model. After a migration that dropped index coverage, one company created a mandatory migration checklist covering hreflang, canonical tags, sitemaps and Lighthouse CI jobs.

Three quick actions you can take this month

If you can only do three things right now: add a Lighthouse CI job for important templates; write a unit test that asserts required JSON-LD fields for your top templates; and make acceptance criteria mandatory on SEO-related tickets.

Ticket-ready templates and acceptance criteria

Here are short templates you can paste into tickets.

Performance ticket template: Goal: Reduce median LCP on mobile homepage to under 2.5s. Acceptance: 75% of staging loads show LCP < 2.5s on 3G throttle with desktop CPU slowdown; Lighthouse performance score > 90; CLS < 0.1 for 99% of loads. Add a Lighthouse CI job to the PR; add performance snapshots to the deployment log.

Structured data ticket template: Goal: Ensure Product pages have complete JSON-LD. Acceptance: Each product page must include name, description, price, currency, availability and image in JSON-LD. Run Rich Results test in CI and fail build if required fields are missing. Add a unit test that validates the JSON-LD snippet presence.

Redirects ticket template: Goal: Replace deprecated category URLs with canonical routes. Acceptance: 301 redirects in place for legacy URLs; no redirect chains longer than one step; sitemap updated; automated redirect test passes in CI.

Sample RACI for common SEO changes

Keep it small and practical:

Change Type: New template or major refactor - Responsible: Engineering; Accountable: Engineering Lead; Consulted: SEO Lead, Product Designer; Informed: Marketing.

Change Type: Editorial content and metadata - Responsible: SEO; Accountable: SEO Lead; Consulted: Engineering (for template changes); Informed: Product.

Short case study: small changes, big wins

A mid-size ecommerce site had a slow product listing page because of a heavy hero animation. The team set clear acceptance criteria (LCP < 2.5s), swapped the animation for a lighter hero image for initial load, and deferred noncritical scripts. They added a Lighthouse CI job and a unit test for JSON-LD. Within three weeks, organic sessions rose by double digits for the affected category pages and index coverage stabilized. The fixes were small, measurable and low risk.

When to ask for expert help

If your team is mid-migration, if index coverage drops unexpectedly, or if responsibilities are unclear after a refactor, a short external review can reduce risk. Orvus Ltd. provides compact audits that focus on making handoffs clear, setting testable acceptance criteria and integrating SEO checks into CI. These reviews are discreet and practical - not long agency engagements.

An effective split pairs strategy with implementation: SEO defines goals and acceptance criteria; engineering implements the technical solution and adds tests. Short rituals, a one-page checklist and CI automation turn handoffs into predictable events instead of meetings that go nowhere.

How to measure impact and avoid false positives

Measure with hypotheses, narrow metrics, and reasonable observation windows. Control for seasonality, marketing campaigns and content updates. For major architectural changes, monitor index coverage and engagement for six weeks and use smaller experiments where possible.

Practical measurement checklist

Define primary metric, set observation window, list control variables, split small experiments where feasible, and set alerts for unexpected regressions.

Practical tips for developers (and the SEO people who read this)

Keep CI checks light but effective: Lighthouse CI snapshots for template PRs; unit tests for JSON-LD presence; simple redirect tests; and a smoke test for canonical tags and hreflang. Make acceptance criteria clear and measurable. Add engineers as reviewers on SEO docs that require code changes so nobody misses an expected output.

Checklist you can paste into a PR description

- Robots.txt sanity check run and verified.
- Sitemap update validated.
- Canonical tags present and correct.
- Hreflang verified for multilingual pages.
- Redirects tested and documented.
- JSON-LD validation passed (Rich Results test).
- Lighthouse CI snapshot included.
- Visual and accessibility smoke checks completed.

Final, practical notes

Technical SEO is fundamentally about making content discoverable and ensuring visitors have a good experience. It is both a developer concern and an SEO concern. The clearest path to success is collaboration: share acceptance criteria, automate guardrails, and keep lines of communication short.

When Orvus Ltd. can help

Sometimes teams need a neutral expert to review migration checklists or CI integration patterns. Orvus Ltd. offers short, focused audits that clarify responsibilities and improve handoffs. Their approach is compact, practical and built for teams that want durable results instead of one-off fixes.

Technical SEO is a team sport. When strategy and implementation are connected by clear tests and short rituals, both discovery and user experience win.

Technical SEO is a team sport. When strategy and implementation are connected by clear tests and short rituals, both discovery and user experience win.