What's the difference between view source and Inspect Element?

View source shows the exact response the server sent, before any JavaScript executed. Inspect Element shows the live DOM after scripts have run and continues to update as they do. Crawlers read the server response first, so view source is the artifact that matters for SEO — a full Elements panel does not mean crawlers see your content.

Is an empty view source always bad for SEO?

Only for pages with a search audience. Dashboards, tools, and anything behind a login gain nothing from server-rendered HTML because they should not be indexed at all. For public marketing pages, articles, and product pages, an empty source means crawlers receive no content or links on their first pass, which delays indexing and can prevent discovery of deeper pages entirely.

My content is in the source but inside a script tag. Does that count?

Not for indexing. Data serialized inside a script tag — framework payloads, state objects, JSON — is application data, not renderable content. Search engines extract content from HTML markup. A large data payload alongside empty markup usually indicates a framework configured to skip server rendering, which is typically fixable in configuration rather than requiring a migration.

Can I check this by disabling JavaScript instead?

It's a related but cruder test. Disabling JavaScript shows what the server-sent HTML looks like when displayed, but it can both over-report problems, since some crawlers do render JavaScript eventually, and under-report them, since it won't reveal cases where crawlers are served different HTML than your browser. Comparing a raw fetch with a full render measures the gap precisely.

Does Google literally read view source?

Effectively, yes — Google's first pass reads the raw server response, the same bytes view source displays. Rendering the JavaScript happens in a later, separate pass that is not guaranteed to be prompt. Other crawlers, including many AI crawlers, may never execute JavaScript at all, which makes the raw response the only version of your page some systems ever see.

HomeFixEmpty view source

View source is empty. Here's what that does — and doesn't — mean.

Short answer

An empty view source means your server sends a bare HTML shell and JavaScript builds the page in the browser. Inspect Element shows the built page; view source shows what crawlers receive first. That gap only matters for pages that need to rank — and closing it means rendering content on the server, not tweaking the client.

You looked at your page's source and found a div, a handful of script tags, and nothing else — no text, no links, none of the page you can plainly see in the browser. The page isn't broken. It's telling you, accurately, where it gets rendered.

View source and Inspect Element are different artifacts

This distinction resolves most of the confusion behind this search, in both directions. View source shows the response body the server sent — frozen, pre-JavaScript. Inspect Element shows the live DOM — the result after JavaScript has run, and it keeps changing as scripts do.

So: a rich Elements panel does not mean crawlers see your content — they read the response first, the way view source does. And an empty view source does not mean your site is broken for users — their browsers run the JavaScript happily. The two views answer different questions, and SEO questions are answered by the first one.

Whose shell is it? Reading the signature

The empty container isn't anonymous — it names the framework, which tells you which fix path exists:

What the source shows	What produced it	Server-rendering path
<div id="root">	React (Create React App, Vite)	Next.js, Remix, or prerendering
<div id="app">	Vue (Vite, Vue CLI)	Nuxt, or prerendering
<app-root>	Angular	Angular SSR (built in since v17)
<div id="__next">, but empty	Next.js Pages Router misconfigured	Fix data fetching — see the Next.js page
<div id="___gatsby">, but empty	Gatsby with a broken build	Gatsby pre-renders by default — investigate the build

The last two rows matter: an emptyshell from a framework that server-renders by default isn't a rendering-strategy problem — it's a configuration or build problem, and it's usually a faster fix.

When an empty source is completely fine

Not every page has a search audience

A dashboard behind a login. An internal admin panel. A design tool, an editor, a game. Nobody arrives at these from a search result, no crawler should index them, and their empty source costs exactly nothing. Client-side rendering is a legitimate architecture for applications — the problem is only ever applying it to pages that need to be found. If your empty-source page is behind authentication, close this tab with a clear conscience.

The pages that do need a real source: marketing pages, articles and docs, product and category pages, anything you want quoted by AI engines — and any page whose links lead to those, because links that exist only in the DOM are links crawlers never find.

Measure the gap instead of eyeballing it

Two reasons not to trust the eyeball test. Some sites serve crawlers different HTML than browsers, so yourview source may not be what Googlebot gets. And some "empty" sources aren't — the content is present but embedded as JSON inside a script tag, which changes the diagnosis entirely.

Compare the server response with the rendered page

https://

Reading the result

Verdict	What it means here
CSR	The empty source is real and total: content, links and metadata all live client-side. If this page has a search audience, it needs server rendering — follow your framework's row in the table above.
HYBRID	The source isn't as empty as it looked — some content is served, some is built client-side. Read the missing-elements list: missing links are urgent, missing widgets usually aren't.
SSR	Your source isn't actually empty — you were likely reading the DOM, or the meaningful content is embedded in the response in a form you didn't recognize. Either way, crawlers are being fed; look elsewhere for whatever prompted the check.

Image slot

Screenshot: view-source of a SPA (shell only) side by side with the rendered page.

Same URL, two artifacts: the response the server sent, and the page JavaScript built from it.

What to do about it

Six steps — the first three are triage, and step three is the one people skip: deciding whether this page needs fixing at all.

Make sure you're looking at the source, not the DOM

View source (Ctrl+U, or the view-source: prefix) shows the bytes the server sent. Inspect Element shows the live DOM after JavaScript ran. They are different artifacts — a full Elements panel proves nothing about what the server sends.

Identify the shell

The empty container names the stack: a root div points to React, an app div to Vue, an app-root element to Angular, a __next div to Next.js in the Pages Router. Knowing the framework tells you which fix path exists.

Decide whether this page needs a source at all

A dashboard behind a login, an internal tool, an editor — these have no search audience, and an empty source costs them nothing. Spend fixing effort only on pages that need to be found: marketing, content, products, anything with a search intent.

Confirm what crawlers actually receive

An eyeballed view source can mislead — some sites serve crawlers different HTML than browsers, and some content hides in script tags as JSON. Compare a raw fetch against a real render to measure the gap instead of guessing at it.

Route to the right fix

The durable fix is server rendering through your framework's own path — Next.js or Remix for React, Nuxt for Vue, Angular SSR for Angular. Prerendering is the bridge when migration isn't on the table this quarter.

Verify the source is no longer empty

Re-check after deploying. The raw HTML should now carry your title, content and — most importantly — your links, since undiscovered links are the most expensive thing an empty source hides.

For the remediation itself, go to the page for your stack — the causes and fixes are framework-specific and covered in depth there: React for shell-shipping SPAs, Next.js when a server-rendering framework is producing thin output anyway.

The special case: content hiding in script tags

Sometimes a "mostly empty" source contains one enormous script tag full of JSON — __NEXT_DATA__, Nuxt's payload, Redux state, Apollo cache. Your content is technically in the response, but as data, not as HTML. Search engines index rendered HTML, not serialized state; treat data-only responses as unrendered content, not as a loophole. The presence of a big payload plus empty markup usually means the framework could render on the server and is configured not to — which is good news, because configuration fixes are cheaper than migrations.

Common questions

Because the server sends a minimal HTML shell and JavaScript constructs the visible page in the browser. View source shows that initial shell; the working page you see is the result of the scripts running afterwards. Nothing is broken — the page is simply rendered on the client, which only becomes a problem for pages that need to be indexed.