SEO Development: Where SEO and Web Dev Actually Overlap

and ask Googlebot to wait. It waits badly.

I tested this on a React SPA client site in Q3 2025. 1,200 product pages, all CSR. Search Console showed only 340 indexed. Migrated to Next.js SSR over three weeks. Six weeks later, 1,147 indexed. Same content, just rendered on the server. That’s the whole lesson.

Schema markup: what to implement, what to skip

Structured data helps search engines understand what your page is about and unlocks rich results. But most teams over-implement it. You don’t need 14 schema types on every page. You need the right one.

High-value schema by page type:

Page Type	Primary Schema	Secondary Schema	Actual Rich Result?
Blog article	Article	BreadcrumbList, Author (Person)	Top Stories, article cards
How-to guide	HowTo (deprecated 2023)	Article + FAQPage	No, use FAQPage instead
Product page	Product	AggregateRating, Offer, Review	Yes, price and stars in SERP
Local business	LocalBusiness	PostalAddress, OpeningHoursSpecification	Knowledge panel data
FAQ page	FAQPage	WebPage	Dropdown in SERP
Event	Event	Offer, Place	Event cards
Video	VideoObject	Clip, BroadcastEvent	Video rich result
Review	Review	Rating, ItemReviewed	Yes (with policy compliance)

Implementation notes: use JSON-LD in the , not microdata in the markup. Google prefers JSON-LD and it separates concerns. Validate every schema change at validator.schema.org AND search.google.com/test/rich-results, because they catch different things.

Skip: Organization schema on every page (once on the homepage is enough), WebSite schema beyond Sitelinks search box, and anything marked “Thing” in schema.org. If the schema type doesn’t unlock a rich result, it’s SEO theater.

URL structure, redirects, and canonicals

URL decisions are hard to undo, so get them right the first time. Short, readable, keyword-aligned, no parameters if you can avoid them. Hyphens, not underscores. Lowercase. No trailing slashes or all trailing slashes, pick one and redirect the other.

Redirect rules that save ranking:

1. Use 301 for permanent moves. Never 302 unless it’s genuinely temporary.
2. Redirect chains lose equity at each hop. Audit quarterly with Screaming Frog. Flatten chains over 2 hops.
3. When you kill a page, redirect to the closest parent, not the homepage. A homepage redirect tells Google the page is gone but you’re too lazy to map it.
4. Update internal links to the final URL. Don’t rely on redirects to do cleanup work for you.

Canonical tags tell Google which URL is the authoritative version when similar content exists. Rules: self-canonical on every page (points to itself), pagination uses self-canonical (not rel="next/prev" anymore, Google deprecated that in 2019), and cross-domain syndication uses canonical back to the original.

The canonical sin I see weekly: pointing every page to the homepage. It happens when a developer copies a canonical tag from a template and forgets to make it dynamic. Google then thinks your whole site is one page. Catastrophic. Audit with curl -I or a full crawl every release.

Server response time and TTFB

Time to First Byte (TTFB) under 600ms is the Google-stated target. Under 200ms is where you want to be. Everything above that compounds into LCP and INP problems downstream.

What kills TTFB in real sites: unoptimized database queries (the #1 cause on WordPress), no object cache (install Redis or Memcached), uncached dynamic pages (add page caching, even on logged-out traffic), bloated PHP/Node processes (profile with Blackfire, Xdebug, or Node’s built-in profiler), and cheap hosting (a $5/mo shared host will never hit 200ms TTFB, move to a $20/mo VPS minimum).

On WordPress specifically: object caching with Redis cuts query count 80% on a 400-post site. Page caching with a plugin like FlyingPress or WP Rocket cuts TTFB from 800ms to 80ms on cached hits. These two changes alone fix most “my site is slow” tickets without touching code.

Indexability: robots.txt, noindex, and the crawl budget

Indexability is the part SEO teams obsess over and dev teams forget exists. It’s the set of signals that tell Google what to crawl and what to skip. Get it wrong and your pages either don’t get indexed or your crawl budget burns on low-value URLs.

The hierarchy of blocking signals:

• robots.txt Disallow: don’t crawl (but the URL can still appear in search without content)
• noindex meta tag: crawl, but don’t index
• X-Robots-Tag HTTP header: same as noindex but works for non-HTML files (PDFs, images)
• 401/403 status: blocked by access control
• 404/410: gone, remove from index

Common mistakes I clean up on audits: blocking JavaScript or CSS in robots.txt (Google needs to render the page, let it), using noindex AND robots.txt on the same URL (Google can’t see the noindex if it can’t crawl), and blocking the staging site with robots.txt then forgetting to remove it on launch. That last one happens roughly every third client migration. Always grep the codebase for “Disallow: /” before going live.

Crawl budget only matters if you have more than 100,000 URLs. Below that, Google can crawl your whole site in a day. Above that, clean up. Kill thin tag pages, remove infinite filter combinations, canonicalize paginated duplicates, and make sure 404s return 404, not 200.

Sitemaps: the handshake with search engines

XML sitemaps tell Google what URLs exist, when they changed, and how important they are. They don’t guarantee indexing, but they help discovery, especially for sites with weak internal linking or fresh content.

What belongs in the sitemap: canonical, indexable, 200-status URLs that you actually want in search. That’s it. Not tag pages if they’re noindexed. Not redirect targets. Not 404s. Not pagination URLs past page 1 (most of the time).

Split sitemaps when you have more than 50,000 URLs or 50MB uncompressed. Use a sitemap index file. Submit the index, not every child. For WordPress, Rank Math and Yoast both handle this. For custom stacks, generate at build time or via cron, not on every request.

The lastmod field actually matters now. Google started trusting it again in 2023 after years of ignoring it. Populate it from your CMS’s actual modified date, not the current date. If every URL has today’s lastmod, Google ignores the signal completely.

Internal linking as a dev responsibility

Internal linking is usually punted to the content team, but it’s a dev problem too. Link structure determines how PageRank flows through your site, and it’s hardcoded in navigation, footer, templates, and block components.

What devs should build:

• Breadcrumbs with BreadcrumbList schema on every page
• Contextual related-posts modules (not just “more from this category”)
• Footer links to your highest-converting pages, not your About page
• A clean taxonomy with no orphan pages (every page reachable in 3 clicks from the homepage)

What to avoid: links in JavaScript-only navigation (Googlebot has to render to find them), rel=”nofollow” on internal links (you’re throwing away your own PageRank), and navigation menus with 200 links stuffed into mega-menus (dilutes every link’s weight).

I audit internal linking with Screaming Frog’s “Crawl Depth” report. Any page more than 4 clicks from the homepage is a candidate for better internal linking. For a Gatilab travel-site client, fixing this moved 312 pages from depth 5-7 down to depth 2-3 over six weeks. Organic traffic to those pages went up 41%.

Monitoring and ongoing work

SEO development isn’t one-and-done. Deployments break things. Frameworks change defaults. Schema specs update. You need monitoring.

Tools I actually use: Google Search Console (free, non-negotiable, set up Property verification for every environment), Screaming Frog (desktop crawler, catches 80% of technical issues), Ahrefs Site Audit (continuous monitoring, alerts on regressions), Lighthouse CI (runs on every deploy, fails builds that regress Core Web Vitals), and Sentry or similar for JavaScript errors that might be breaking crawl.

Bake SEO into the PR checklist, not a quarterly audit. If every PR has to pass Lighthouse CI, schema validation, and a link-checker, regressions get caught before they ship. If SEO is only reviewed quarterly, you spend the quarter between audits fighting fires.

The handoff document that actually works

Every Gatilab engagement ends with a handoff doc. It’s boring. It’s also what keeps the work alive after we leave. Copy this structure.

Sections: current tech stack (framework, host, CDN, rendering method), SEO-critical configs (robots.txt rules, sitemap generation, canonical logic, schema templates), Core Web Vitals targets (per page type, with thresholds), deployment checks (what must pass before merge), and a “known issues” list with links to tickets.

The doc lives in the repo, not in Notion. When the repo is the source of truth, it stays current. When the doc lives somewhere else, it rots within a quarter.

The verdict

SEO development is a specialty, not a side quest. It sits between two disciplines that rarely communicate, and the people who can translate between them are rare, valuable, and busy. If you’re a developer, learn enough SEO to know which tickets actually matter. If you’re an SEO, learn enough dev to write tickets engineers will take seriously.

The sites that win at search aren’t the ones with the cleverest strategy or the most content. They’re the ones where strategy and code line up, release after release, without friction. That alignment is the whole game. Everything else is noise.