To view page source, press Ctrl+U in Chrome, Edge or Firefox on Windows (Cmd+Option+U in Chrome on a Mac), or type view-source: in front of any URL. What opens is the raw HTML your server sent, before any JavaScript ran. But the source is only one of three versions of your page, and the SEO bugs that cost rankings usually live in the gap between them. This guide shows what to check, in what order, and how to tell which version Google actually used.
The Three Versions of Every Page
Every URL you audit has three layers, and each one answers a different question:
- The HTTP response headers. Status code, redirects, and header-level rules such as
X-Robots-Tagor a canonical sent as aLinkheader. None of this appears in the page source. - The raw HTML. The document the server returned. This is what view source shows, and it is what Googlebot reads on the first pass.
- The rendered DOM. The page after the browser (or Google’s headless Chromium) has run the JavaScript. This is what Inspect Element shows, and Google’s JavaScript SEO documentation says Google “also uses the rendered HTML to index the page.”
The practical rule: raw HTML tells you what every crawler is guaranteed to see; rendered HTML tells you what Google can see once rendering happens. When the two disagree on anything that controls indexing, you have found a problem worth fixing.
How to View Page Source in Every Browser
The shortcut varies by browser, and Safari hides the option by default.
| Browser | Raw source | Rendered DOM |
|---|---|---|
| Chrome / Edge (Windows, Linux) | Ctrl+U, or right-click and choose View page source | F12 or right-click, Inspect |
| Chrome (Mac) | Cmd+Option+U | Cmd+Option+I |
| Firefox | Ctrl+U (Cmd+U on Mac) | F12, Inspector tab |
| Safari (Mac) | Turn on “Show features for web developers” in Settings, Advanced, then Develop, Show Page Source (Option+Cmd+U) | Develop, Show Web Inspector |
| Any Chromium or Firefox browser | Type view-source: before the full URL in the address bar |
n/a |
One caveat: the source reflects your request, with your cookies, location and logged-in state, so an admin bar or geo-redirect can make your copy differ from what a crawler receives. Use a private window, and confirm anything important in Google’s own tools (covered below).
Raw vs Rendered HTML: Why the Difference Decides Indexing
Google describes its pipeline as crawl, render, index. Googlebot fetches the raw HTML, parses it for links, and queues pages that return 200 for rendering, where headless Chromium executes the JavaScript “once Google’s resources allow.” Google says that wait can be seconds or longer. Our explainer on JS rendering and the two-wave index covers the mechanics in depth.
Three consequences matter for anyone reading source code for SEO:
- Links in raw HTML are found immediately. Links that only exist after rendering are discovered later, which slows crawling of deeper pages.
- A raw
noindexcan stop rendering entirely. Google warns that when it seesnoindex, “it may skip rendering and JavaScript execution.” So JavaScript that removes a noindex may never run. - Not every reader renders. Google’s own guide notes that “not all bots can run JavaScript.” Link-preview fetchers and many other crawlers work from the raw response, so Open Graph tags injected client-side are a gamble.
View Source vs Inspect Element: When to Use Which
Inspect Element is not a better view source. It is a different document. DevTools shows the live DOM: everything JavaScript added, removed or rewrote, plus the browser’s repairs to broken markup. That makes it great for checking what rendered, and misleading for checking what the server sent.
| Question | Use |
|---|---|
| Is the title, canonical or meta robots in the server response? | View source |
| Did JavaScript change the title, canonical or robots tag? | Compare both |
| Is the main content in the HTML or loaded by an API call? | View source, then search for a sentence from the body |
Is a noindex or canonical sent as a header? |
DevTools Network tab, response headers |
| What did Google actually render? | URL Inspection or the Rich Results Test |
A fast way to feel the gap: open DevTools, press Ctrl+Shift+P (Cmd+Shift+P on Mac), run “Disable JavaScript” and reload. What is left is roughly what a non-rendering crawler gets.
The Source Code SEO Checklist: What to Search For
Do not read the source top to bottom. Press Ctrl+F (Cmd+F) in the view source tab and search for each string below. Each check takes seconds.
| Search for | What good looks like | Red flag |
|---|---|---|
<title |
Exactly one, unique, describing the page | Missing, duplicated, or a placeholder like the site name only |
name="robots" |
Absent (defaults to index, follow) or the rules you intended | noindex left over from staging, or a second conflicting robots tag |
rel="canonical" |
One tag, absolute URL, pointing at the page itself or the true original | Two canonicals, a relative URL, or one pointing at the homepage |
hreflang |
Every language version listed, including the page itself, with full URLs | Missing self-reference or return tags |
application/ld+json |
Valid JSON describing what is visible on the page | Markup for content that is not on the page, or none where you expected it |
<h1 |
One clear main heading in the raw HTML | No heading until JavaScript runs |
| A sentence from your body copy | Found in the raw source | Not found: content depends on rendering |
og:title |
Present in the raw HTML | Only injected client-side |
Two of those rows deserve a note. For robots, Google says that “in the case of conflicting robots rules, the more restrictive rule applies,” so a stray second tag with noindex wins over an index tag. Our meta robots tag guide lists every directive. For hreflang, Google requires that “each language version must list itself as well as all other language versions,” with fully qualified URLs; the hreflang tags guide walks through the return-tag logic.
The Head Trap Nobody Mentions
Here is the check most view-source tutorials skip. Google’s documentation on valid page metadata lists the elements allowed in the head (title, meta, link, script, style, base, noscript, template) and states that once it detects an invalid element, it “assumes the end of the <head> element” and “stops reading any further elements” there. Google names iframe and img as examples.
It usually happens when someone pastes a tracking pixel or embed into the header template above the SEO plugin output. The canonical, robots tag and hreflang below it still look fine to a human, and are silently ignored.
So in view source, scroll the head and check the order: any <img or <iframe sitting above your canonical or robots tag is a bug. Inspect Element gives you a second tell. Browsers end the head early when they hit an invalid element, so in the Elements panel your canonical and meta tags will appear inside the body instead of the head. If your canonical shows up under the body in DevTools, look for what broke the head above it.
Two Worked Examples
The page that will not index
A product page shows “Excluded by ‘noindex’ tag” in Search Console, yet Inspect Element shows <meta name="robots" content="index, follow">. View source tells the real story: the server sends <meta name="robots" content="noindex">, and a script flips it after load. Per Google’s guidance, the raw noindex can cause Google to skip rendering, so the flip never counts. The fix is in the server template, not the JavaScript: “if you do want the page indexed, don’t use a noindex tag in the original page code.”
The canonical that changes its mind
A filtered category URL has a raw canonical pointing at itself. After rendering, a script rewrites it to the parent category. Google’s canonicalization docs say to “make sure that JavaScript doesn’t change the canonical link element,” and if you cannot set it in the HTML source, to leave it out and only set it with JavaScript. Pick one layer and make it the only one. The canonical tag guide explains why Google may ignore a declared canonical even when it is consistent.
What View Source Cannot Tell You
Treat the source as one witness, not the whole trial. It is blind to:
- HTTP headers. An
X-Robots-Tag: noindexheader blocks indexing without a trace in the HTML. Check the Network tab: click the document request and read the response headers. - Status codes and redirects. A soft redirect or a 200 that should be a 404 looks normal in the source.
- Robots.txt blocking. If a URL is disallowed, Google says “any information about indexing or serving rules will not be found,” so a noindex in the source does nothing there.
- Truncation. Googlebot’s documentation says it crawls “the first 2MB of a supported file type,” HTML included, and that the limit “is applied on the uncompressed data.” If your source scrolls forever because of a huge inline state blob, content near the bottom may never be read. Save the source and check the file size.
How to See What Google Actually Rendered
Your browser’s render is a proxy. For Google’s own view, its JavaScript SEO guide points to two tools: the URL Inspection tool in Search Console and the Rich Results Test, then says to look at the rendered HTML. “If the content isn’t visible in the rendered HTML, Google won’t be able to index it.” Our URL Inspection tool guide covers every panel, including the live test screenshot and the user-declared versus Google-selected canonical.
For structured data, Google confirms it “can understand and process structured data that’s available in the DOM when it renders the page,” and recommends testing with the URL input of the Rich Results Test rather than pasted code. One exception: Google warns that dynamically generated markup “can make Shopping crawls less frequent and less reliable,” so ecommerce sites should keep price and availability in the raw HTML. More in how to test structured data.
Comparing Raw and Rendered HTML at Scale
For a single page, the manual diff works well. Copy the raw source, then in DevTools right-click the html element and choose Copy, Copy outerHTML. Run both through the Code Minifier and Beautifier so formatting differences disappear, then paste them into the Text Compare Tool. Changed titles, canonicals, robots tags and missing body copy stand out immediately.
Across a whole site, you need a crawler that renders JavaScript. The SEO Rocket site audit runs on a real crawler (Screaming Frog-backed) with JavaScript rendering, so it checks every URL, not just the one you happened to open, and surfaces 404s, redirect chains and broken links alongside the page-level problems. From there you can ask the chat to summarise which page types the issues cluster on, which is usually where the fix belongs. For a single stuck URL, pair view source with the Meta Tag Analyzer and the diagnostic order in our Chrome SEO audit guide.
FAQ
Is view page source the same as what Google sees?
It is what Googlebot fetches first, but Google indexes the rendered HTML. Use view source for raw HTML and URL Inspection or the Rich Results Test for Google’s render.
Why does view source look different from Inspect Element?
View source shows the server response. Inspect Element shows the live DOM after JavaScript and the browser’s error correction. Differences mean scripts or broken markup changed the page.
Can I view page source on a competitor’s site?
Yes. Any public page’s HTML is visible to every visitor. It is a quick way to see a competitor’s titles, schema types and heading structure.
Does JavaScript-added content get indexed?
Often, yes, because Google renders pages. But rendering can be delayed, a raw noindex can prevent it, and other crawlers may not render at all, so critical tags belong in the raw HTML.
Make It a Habit, Not a Rescue
The cheapest SEO bugs are the ones caught before launch. Every time a template, plugin or tag manager container changes, view page source on one URL per template and run the eight searches above, then check the head order and the response headers. It takes a few minutes, and it catches the noindex, canonical and hreflang mistakes that otherwise surface weeks later as an indexing report you cannot explain. That habit sits at the core of the audit playbook proven across 1,000,000+ ranking pages, and SEO Rocket’s audit runs the site-wide version of it on every crawl.
