SEO for Developers: What Your Framework Means for Rankings

Most SEO advice is written for marketers. Keywords, meta descriptions, backlinks. That’s all important, and I’ve covered SEO for local businesses elsewhere.

This post is different. It’s for developers, the people making the technical decisions that determine whether a site can even be crawled, indexed, and ranked in the first place.

Your framework choice, your rendering strategy, and your performance optimizations matter more for SEO than most developers realize. A beautifully optimized content strategy means nothing if Googlebot can’t see your pages.

---

How Google Actually Crawls Your Site

Understanding search engine crawling eliminates most SEO confusion for developers.

Step 1: Discovery. Googlebot finds your URLs through sitemaps, internal links, and external links pointing to your site.

Step 2: Crawling. Googlebot requests the URL and receives an HTTP response. If the response is a complete HTML document, Google can parse it immediately. If it’s a minimal shell that requires JavaScript to render content, Google queues it for rendering.

Step 3: Rendering. For JavaScript-heavy pages, Google runs a headless Chrome instance to execute your JavaScript and produce the final HTML. This step is resource-intensive and has a limited budget, so not all pages get rendered quickly.

Step 4: Indexing. Google parses the final HTML, extracts the content, and decides whether and where to rank it.

The critical takeaway: server-rendered HTML is indexed faster and more reliably than JavaScript-rendered HTML. Google can render JavaScript, but it’s slower, less reliable, and subject to a crawl budget that may not cover your entire site.

---

Rendering Strategies and Their SEO Impact

I wrote a detailed comparison of SSR, SSG, and CSR in SvelteKit previously. Here’s the SEO-specific lens.

Static Site Generation (SSG): Best for SEO

Pre-rendered HTML served from a CDN. Googlebot receives complete content on the first request. No rendering step needed.

SEO advantages:

• Complete HTML available immediately
• Fastest possible page load (great for Core Web Vitals)
• Zero dependency on JavaScript for content visibility
• Cacheable at the edge for consistent performance

Best for: Blog posts, documentation, marketing pages, landing pages, product listings that change infrequently.

Server-Side Rendering (SSR): Excellent for SEO

HTML generated on the server per request. Googlebot receives complete content, just like SSG, but the server does work on each request.

SEO advantages:

• Complete HTML on first request
• Content is always fresh (no stale cache)
• Can personalize content while remaining crawlable

SEO risks:

• Slower TTFB than SSG if the server is under load
• Server errors (500s) during crawling can hurt indexing

Best for: Dynamic content that changes frequently, search results pages, authenticated content that also needs public-facing SEO.

Client-Side Rendering (SPA): Risky for SEO

The server sends a minimal HTML shell. JavaScript fetches data and renders the page in the browser.

SEO risks:

• Googlebot may not render the page, or may render it with delays
• Content might not be indexed at all
• No fallback if JavaScript fails
• Poor Core Web Vitals (large JavaScript bundles, late content paint)

When it’s acceptable: Behind authentication (dashboards, admin panels) where SEO doesn’t matter. Never for content that needs to rank.

The Practical Rule

If the page needs to appear in search results, ensure the server sends complete HTML. Whether that’s SSG or SSR depends on your data freshness needs. But never rely on client-side rendering for pages you want Google to find.

---

Core Web Vitals: The Performance Metrics Google Measures

Google uses three performance metrics (Core Web Vitals) as ranking signals. They measure real-user experience, not synthetic benchmarks.

Largest Contentful Paint (LCP)

What it measures: How long until the largest visible element (usually a hero image or heading) finishes loading.

Target: Under 2.5 seconds.

Developer impact:

• Optimize your largest image (use WebP/AVIF, proper sizing, loading="eager" for above-fold images)
• Server-render your content so the browser doesn’t wait for JavaScript
• Use a CDN for static assets
• Preload critical fonts with <link rel="preload">

Cumulative Layout Shift (CLS)

What it measures: How much the page layout shifts as it loads. Content that jumps around is disorienting.

Target: Under 0.1.

Developer impact:

• Set explicit width and height on images and videos
• Reserve space for dynamically loaded content (ads, embeds)
• Avoid injecting content above existing content after initial render
• Use CSS aspect-ratio for responsive media containers

Interaction to Next Paint (INP)

What it measures: How quickly the page responds to user interactions (clicks, taps, key presses).

Target: Under 200 milliseconds.

Developer impact:

• Minimize main-thread JavaScript work
• Break long tasks into smaller chunks
• Defer non-critical JavaScript with async or defer
• Use requestIdleCallback for low-priority work

How to Measure

Google PageSpeed Insights: lab data for any URL. Free.

Google Search Console: real-user data aggregated across your site. Shows which URLs pass or fail Core Web Vitals.

Chrome DevTools Lighthouse: local testing during development.

---

Technical SEO Checklist for Developers

Semantic HTML

Search engines parse HTML structure to understand content hierarchy. Use semantic elements:

<main>
  <article>
    <h1>Page Title</h1>
    <p>Introduction paragraph...</p>
    <h2>First Section</h2>
    <p>Section content...</p>
  </article>
  <aside>
    <nav aria-label="Related posts">...</nav>
  </aside>
</main>

This isn’t just accessibility. It’s how Google understands which content is primary, which is secondary, and how the page is organized.

Heading Hierarchy

Use one <h1> per page. Follow the hierarchy sequentially: <h1> → <h2> → <h3>. Don’t skip levels. Don’t use headings for styling; use CSS for that.

Google uses heading structure to understand your content’s organization. A page with a clear heading hierarchy ranks better than one where headings are used decoratively.

Meta Tags

The basics that every page needs:

<title>Page Title | Site Name</title>
<meta
  name="description"
  content="A concise summary of this page's content (150-160 characters)."
/>
<link rel="canonical" href="https://yourdomain.com/this-page" />

Title: Keep it under 60 characters. Front-load the important keywords.

Description: This appears in search results. Write it for humans, not algorithms. Make people want to click.

Canonical: Tells Google which URL is the “official” version if the same content is accessible from multiple URLs.

Open Graph and Social Meta

When someone shares your page on social media, these tags control what appears:

<meta property="og:title" content="Page Title" />
<meta property="og:description" content="Page summary" />
<meta
  property="og:image"
  content="https://yourdomain.com/images/og-image.jpg"
/>
<meta property="og:url" content="https://yourdomain.com/this-page" />
<meta name="twitter:card" content="summary_large_image" />

A page shared without OG tags looks like an afterthought. A page with a good OG image and title gets clicked.

Sitemap

Generate a sitemap that lists every page you want indexed. In SvelteKit, I prerender the sitemap at build time:

// src/routes/sitemap.xml/+server.ts
export const prerender = true;

export function GET() {
  const pages = getAllPages(); // Your logic to enumerate pages
  const xml = generateSitemapXml(pages);
  return new Response(xml, {
    headers: { "Content-Type": "application/xml" },
  });
}

Submit your sitemap to Google Search Console. Update it whenever you add or remove pages.

Robots.txt

Tell crawlers what to index and what to skip:

User-agent: *
Allow: /
Disallow: /api/
Disallow: /admin/
Sitemap: https://yourdomain.com/sitemap.xml

Block API routes, admin panels, and any other pages that shouldn’t appear in search results.

Internal Linking

Every page should be reachable through internal links, not just the sitemap. Google discovers pages by following links, and internal links distribute “authority” across your site.

A blog post that links to related posts, service pages, and your contact page helps Google understand your site’s structure and keeps visitors engaged longer. This is why every post on this blog cross-links to related content.

---

Framework-Specific Considerations

SvelteKit

SvelteKit’s per-route rendering configuration makes it SEO-friendly by default. Prerender static content, SSR dynamic content, and you’re covered.

Watch for: Client-side routing can confuse crawlers if not implemented correctly. SvelteKit handles this well with its data-sveltekit-preload-data attributes, but verify that Google sees your pages correctly using the URL Inspection tool in Search Console.

Next.js

Similar to SvelteKit, it supports SSG, SSR, and ISR (incremental static regeneration). The App Router defaults to server components, which is good for SEO.

Watch for: Client components that load content dynamically after the initial render. Ensure critical content is in server components.

React SPA (Create React App, Vite + React)

Pure client-side rendering. Poor for SEO out of the box. If you need SEO, add SSR with a framework like Next.js or Remix, or prerender routes with a tool like react-snap.

Vue / Nuxt

Nuxt provides SSR and SSG similar to SvelteKit and Next.js. Vue SPAs without Nuxt have the same CSR limitations as React SPAs.

---

Testing Your SEO Implementation

Google Search Console URL Inspection

The most important tool. Enter any URL from your site and Google shows you:

• Whether the page is indexed
• The rendered HTML that Google sees
• Any crawling or rendering errors
• Mobile usability issues

If Google’s rendered view doesn’t match what you see in your browser, your JavaScript rendering isn’t working correctly for crawlers.

Lighthouse SEO Audit

Chrome DevTools → Lighthouse → check “SEO.” This catches the mechanical issues: missing meta tags, non-crawlable links, missing alt text, viewport configuration.

View Page Source

The oldest trick. Right-click → View Page Source. If your content is there, Google can see it. If it’s not (because JavaScript renders it), Google might not.

---

The Developer’s SEO Priority List

If you’re a developer who’s been ignoring SEO, here’s where to start:

1. Ensure server-rendered HTML. This is the foundation. Everything else is optimization.
2. Add meta tags (title, description, canonical) to every page.
3. Generate and submit a sitemap.
4. Check Core Web Vitals and fix any failing metrics.
5. Use semantic HTML and proper heading hierarchy.
6. Add internal links between related pages.

These six items cover the technical SEO fundamentals. Get them right, and you’ve eliminated the most common reasons that developer-built sites fail to rank.

The content and marketing side of SEO (keywords, local optimization, reviews) builds on top of this technical foundation. Without the foundation, none of that matters.

Your framework isn’t just a developer experience choice. It’s an SEO decision. Choose accordingly.