JavaScript SEO: SPAs, SSR and prerendering

0:00 JavaScript SEO

Here's a question that saves hours of debugging. What does the very first HTML response of your page contain? Not what you see in the browser after everything loads. The first response. In this lecture you'll learn why that question matters so much, how rendering strategies compare, the non-negotiables for JavaScript sites, what Google clarified in late twenty twenty-five, and how to diff raw and rendered HTML yourself with a short Python script.

0:32 Why it matters

On a classic server-rendered site, the first response already contains the text, the links and the meta tags. On a client-side single-page app, it can be an empty div and a script tag. Everything search engines need only exists after JavaScript runs. Google can render JavaScript, but rendering is an extra step with extra ways to fail. And many other crawlers, including social preview bots and several AI crawlers, don't run JavaScript at all. Think of it as sending flat-pack furniture. Google will assemble it. Many others will just look at the box.

1:12 Rendering strategies

Let's compare strategies. Client-side rendering builds the page in the browser, so it carries the highest SEO risk. Server-side rendering returns full HTML per request and then hydrates, which is low risk if hydration doesn't change the content. Static site generation builds HTML at deploy time, the lowest risk, great for content that changes infrequently. Incremental regeneration rebuilds static pages on a schedule or trigger. And dynamic rendering, serving prerendered HTML to bots and the app to users, is something Google calls a workaround, not a long-term solution.

1:50 Non-negotiables 1–4

Now the non-negotiables. One: real links. Google discovers links from anchor elements with an href. A span with an onclick handler isn't a link. Two: real URLs, not hash fragments. Use paths like slash products slash red-shoes; Google generally ignores everything after the hash. Three: correct status codes. An app that shows product not found but returns two hundred creates soft four-oh-fours; route unknown paths to a real four-oh-four from the server. Four: don't block the JavaScript, CSS or API endpoints your pages need to render.

2:27 Non-negotiables 5–6

Five: put meta tags in the initial HTML where you can. Google usually honours titles, canonicals and robots meta set by JavaScript after rendering, but conflicting values between raw and rendered HTML make results unpredictable. And here's what Google made explicit in December twenty twenty-five. When it sees noindex, it may skip rendering, so a noindex in the raw HTML that JavaScript later removes may never be seen as removed. And pages with non-two-hundred status codes may not be rendered at all. Six: lazy-load safely, with native loading equals lazy or intersection observers, never scroll events for primary content.

3:10 Hydration mismatches

Hydration mismatches deserve a moment. With server-side rendering, the server sends HTML, and client JavaScript then hydrates it. If the client renders something different, say a different price, or a different canonical because of a locale cookie, Google may index whichever version it saw. The only way to catch this is comparing raw HTML with rendered HTML. Which brings us to the hands-on.

3:37 Hands-on: raw vs rendered diff

The lesson text has a Python script that fetches a URL twice. Once with requests, which gives you the raw HTML. And once with Playwright's headless Chromium, which gives you the rendered HTML. It summarises both: title, canonical, robots meta, number of unique links and word count, and flags any differences. A different canonical or robots value is high severity. Big differences in links or words mean the page depends on rendering. One caveat: Playwright isn't Google's renderer, so confirm important findings with URL Inspection's rendered HTML.

4:15 Example 1: Dubai React catalogue (illustrative)

Worked example one, with illustrative details. A Dubai e-commerce brand rebuilt its catalogue as a React single-page app. Category pages returned only the shell, and products loaded from an API path that was disallowed in robots.txt to save crawl budget. URL Inspection showed an empty grid, so Google saw thin category pages with no product links. The fix: allow the API path, move category and product templates to server-side rendering, output product links as real anchors, and return four-oh-four for discontinued products. Then watch the Page indexing report over the following weeks.

4:55 Example 2: 'our framework does SSR' (illustrative)

Worked example two, also illustrative. A Lahore SaaS company says its Next.js marketing site is server-rendered, so JavaScript SEO isn't a concern. The diff shows the raw HTML of the pricing page contains only a loading skeleton, because the pricing component fetches plans on the client after hydration. The fix is fetching plan data at build or request time. And a second finding: the locale switcher changes the canonical on the client based on a cookie. The fix is rendering the canonical on the server from the URL path only. A framework that can do SSR doesn't mean every component does.

5:39 Watch me do it: auditing a JS template

Watch me do it. I'll audit a JavaScript category template in fifteen minutes. Step one: I pick one category URL and run the Playwright diff script from the lesson. The output shows title identical, robots identical, canonical identical. But links: raw thirty-eight, rendered two hundred and twelve. And words: raw one hundred and ninety, rendered one thousand four hundred. So this page depends on rendering for its product grid. Step two: I open Search Console URL Inspection, test live, and view the tested page's HTML. I search for the name of the twentieth product in the grid. It's there. So Google can render it today, which is good, but it's a dependency. Step three: I open the More info tab. One resource failed to load: the reviews script, blocked by robots.txt on a subdomain. Not critical, but noted. Step four: I disable JavaScript in Chrome DevTools and reload. The grid disappears. That's roughly what non-rendering crawlers see, including several AI crawlers. Step five: I write the ticket: render the first page of products on the server, as real anchor links, and keep client-side filtering for later pages. And I add the diff to our release checks.

7:04 Common mistakes

Common mistakes. Testing only in a browser where you're logged in or have cookies. Relying on dynamic rendering indefinitely and letting the bot version drift from the user version, which can look like cloaking. Infinite scroll with no paginated URLs. And forgetting that social, many AI and some search crawlers don't run JavaScript at all. How do you measure success? The share of key templates where title, canonical, robots and main content match between raw and rendered HTML.

7:38 Recap and try this now

Recap. For anything you want indexed, send meaningful HTML in the first response. Use real links, real URLs and real status codes. Don't block resources. Keep noindex and canonicals consistent from the start, because noindex can stop rendering and non-two-hundred pages may not render. Try this now. Run the diff script on one URL from each of your main templates, and list every row marked differs. Each one is either a fix or a documented decision.