Developer inspecting a webpage's HTML source on a laptop

Start with a question, not a scan

A source inspection becomes useful when the conclusion is narrow enough to verify. Instead of asking whether a page is “good for SEO,” write the question you can answer from returned HTML: does the response contain a canonical link, is the main heading present, or is a JSON-LD block delivered in the document? A focused question tells you what to search for and prevents one response from being treated as a complete website audit.

  • Metadata question: Is the <title>, description, canonical, or robots directive present in the response?
  • Content question: Does the returned HTML contain the heading, paragraph, product name, or other text a reader needs?
  • Structure question: What order do the H1-H6 elements, landmarks, links, and scripts appear in?
  • Delivery question: What status, final URL, and response context surrounded the HTML?

Understand what “page source” means

A browser receives an HTTP response and parses the returned text into a document. The HTTP Semantics specification describes the request-and-response boundary, while the HTML Standard's document model describes the document created from HTML. View Source is concerned with the response representation; Inspect or Elements shows the browser's current document after parsing, scripts, and interaction may have changed it.

Response HTML

<head>
  <title>Source inspection example</title>
</head>
<body>
  <h1>Inspect the response</h1>
  <div id='app'></div>
  <script src='/app.js'></script>
</body>

Current DOM after JavaScript

<h1>Inspect the response</h1>
<section class='loaded-result'>Content added after load</section>

The second view may be useful for debugging what a person sees, but it does not change what the first response contained. Keep the two observations separate in your notes: “present in returned HTML” and “present in the live DOM” are different claims.

Retrieve one public response and record its context

Use the complete address for the page you mean to inspect. A redirect, query parameter, cookie, or login state can change the response, so record the input and the final URL rather than saving only a copied fragment. SolViewer's View Source tool is intended for retrieving and reading the returned HTML from one public webpage.

  • Copy the exact public URL, including https:// and any query string that affects the document.
  • Run the URL through View Source or the browser's source view. If the request redirects, note the final URL separately.
  • Record the date and the question being checked. A later request can return different markup.
  • Save only the relevant markup plus enough surrounding context to explain what element or attribute it belongs to.
  • If the response is unavailable, describe it as a retrieval result. Do not turn a blocked request into a claim that the target page is offline.

Find evidence in the head and body

Search for the element that answers the question, then read its context. The <head> normally contains document metadata such as <title>, <meta>, <link>, stylesheets, and scripts. The <body> contains the document's content and controls. The HTML document structure guide explains how to interpret those regions without confusing a tag's presence with a guarantee about what a browser or crawler will do with it.

  • For a title or description, inspect the exact <title> or <meta name='description'> value in the head.
  • For a canonical question, inspect <link rel='canonical' href='...'> and check whether the URL is valid and appropriate for the page.
  • For a content question, search for the exact text and then inspect the element around it. Text inside a script, template, comment, or hidden region is not the same as ordinary page content.
  • For structured data, locate the <script type='application/ld+json'> block, then validate its JSON and compare its claims with visible content.
  • For headings and links, read the surrounding outline instead of judging one tag in isolation.

Work through a small source example

Suppose you need to confirm that a page sends a canonical URL and a main heading. This fragment contains evidence for both observations, but it does not prove that the canonical is the best choice or that the page is indexed. Those are separate decisions that require more context.

<head>
  <link rel='canonical' href='https://example.com/guides/source'>
</head>
<body>
  <main>
    <h1>How to inspect page source</h1>
    <p>Read the returned document before comparing it with the live DOM.</p>
  </main>
</body>
  • Observation: a canonical link element is present in the returned markup.
  • Observation: one H1 is present inside the main content in this fragment.
  • Not established: whether the URL resolves, whether another signal conflicts with it, or whether a search engine selects it.
  • Next check: open the source around the element, inspect response headers when relevant, and use deployed-page or search-engine data for indexation questions.

When source and the visible page disagree

A mismatch usually means that you are comparing two stages of delivery. JavaScript may insert text, request data from an API, change attributes, or replace a loading shell. Cookies, authentication, redirects, experiments, device conditions, and bot protection can also change the response. Google explains that its search process includes crawling, rendering, and indexing, so a source-only observation should not be presented as a complete description of what Google sees. See Google's JavaScript SEO basics for that distinction.

  • Write down what is missing from source and where it appears in the live DOM.
  • Check whether the missing element is inserted after load, revealed after interaction, or dependent on session data.
  • Compare the Network response and the Elements panel when debugging a page you control.
  • If the question is about search visibility, continue with rendered testing and search-engine tools rather than assuming either view is universal.

What page source cannot establish

Returned HTML is valuable evidence, but it has a defined boundary. One retrieval cannot reveal backend application code, database queries, private files, credentials, or content that the request was not authorized to receive. It also cannot by itself prove accessibility conformance, security, performance, search ranking, or indexation.

  • Use HTTP Header Checker when the question concerns status codes, redirects, or response headers.
  • Use HTML Extractor when you need readable text from one returned or supplied document.
  • Use Heading Checker when you need a focused H1-H6 outline.
  • Use SEO Checker for a broader set of observable page-level signals, while keeping its limitations in the conclusion.

Turn the inspection into a repeatable record

A short inspection note is more useful than a screenshot with no explanation. Capture the input, the evidence, the scope, and the next check. This makes it possible for another person to reproduce the observation without pretending that one response answers every question.

  • URL checked and final URL after redirects
  • Date and request condition that may matter
  • Exact question, such as “Does the returned HTML contain a canonical link?”
  • Small markup fragment or heading outline that supports the observation
  • Conclusion limited to what was observed
  • Next verification if source is insufficient: live DOM, headers, validator, rendered test, or Search Console

If your next task is to extract the page's readable text rather than study every tag, continue with How to Extract HTML From a Website. For the larger map of <head>, <body>, and semantic elements, read the HTML document structure guide.

Frequently asked questions

Does View Source show JavaScript-generated content?

Usually not if the content was added after the initial response. View Source shows the retrieved HTML, while the live DOM may include changes made by scripts, interaction, or later data requests.

Is View Source the same as Inspect Element?

No. View Source is a response-oriented view; Inspect Element shows the browser's current DOM. Use the first for delivered markup and the second for runtime debugging, and record which one produced your evidence.

Can I view page source on a phone?

Yes. Enter the public URL in SolViewer's View Source to retrieve the available HTML without relying on a desktop browser's source command. The result still represents one public request, not every version of the page.

Can page source reveal backend code?

No. It can show only the content included in the response. Server-side logic, database queries, private files, and credentials remain on the server unless the site has accidentally published them.

Does valid source mean a page is SEO-friendly?

No. Source inspection can verify observable markup, but it cannot fully evaluate usefulness, search intent, rendering, indexation, performance, or accessibility. Use the evidence to choose the next check instead of treating it as a verdict.

Sources

Continue exploring

Related guides and tools

Editorial note

SolViewer develops the tools linked in this guide. They are included when they help with the next practical step; they do not replace browser testing, official documentation, or professional review where those are needed.