Technical foundations
Check whether key content reaches the initial HTML
Compare page source, rendered content and Google inspection results, then choose a focused server-rendering or static-generation fix.
TL;DR
- Search the initial HTML for the facts that explain what you sell and who it serves.
- Missing text is a diagnostic clue, not proof that Google cannot render the page.
- Compare the original response, browser-rendered content and Google inspection evidence.
- Use server rendering or static generation where it removes a real content dependency.
Checking page source is a useful first test for content that depends on JavaScript. Open a public product or service page and search its source for a distinctive sentence. If the sentence appears on screen but is missing from the response, trace how it reaches the page. Then choose a fix.
Google runs JavaScript and uses rendered HTML for indexing. It also recommends server-side or pre-rendering because not all bots run JavaScript. The conclusion is to inspect the delivery path, rather than declaring every JavaScript page unreadable. Google's JavaScript SEO guide.
In an April 2024 study focused on nextjs.org, Vercel and MERJ matched more than 37,000 Googlebot fetches with rendering signals. The median delay was 10 seconds, the 75th percentile was 26 seconds, and the 90th percentile was about 3 hours. These are observations from that study, not service promises or figures for other crawlers. They show why a missing sentence in page source is not enough to diagnose a Google indexing failure. Study methods and rendering results.
Compare three different views
The initial HTML is the server's response before the browser executes page scripts. The rendered page is the result after those scripts and other resources have run. Google inspection shows what Google found in the indexed version or a live test.
These views answer different questions. A browser may show content because it has a session, cached data or a successful API request. Another visitor may receive a different result. The MDN client-server overview explains how servers can build an HTML response from product data, rather than sending only an empty application shell.
| Evidence | Question | Record |
|---|---|---|
| Page source or saved HTML response | Are the core facts in the initial response? | URL, date, status and exact text searched. |
| Rendered page in a fresh session | What appears after scripts run? | Visible content, failed resources and required interactions. |
| Search Console inspection | What does Google's available inspection evidence show? | Test type, time, rendered HTML and relevant warnings. |
| Published fix | Did the agreed content dependency change? | Before-and-after response and repeat of the same checks. |
Do not treat text inside an embedded JSON payload as equivalent to a visible HTML paragraph. A string search can find the words while the page still depends on code to display them. Check how the text is represented.
Worked example: product facts arrive too late
Illustrative example: a fictional solar street-light manufacturer.
The page says “Solar street light manufacturer for municipal projects” and shows a specification table. View Source contains only a loading container and scripts. The product API supplies all visible details after the browser starts.
In a fresh session, the team finds that an API error leaves the page at “Loading.” The team has found a clear problem. The key sales content depends on a browser request that can fail. Google inspection is checked separately; the team does not assume that a browser failure describes every Google crawl.
The developer moves the approved product description and specification table into generated HTML. Interactive quote controls remain client-side. The response now includes readable content such as:
<main>
<h1>Solar street lights for municipal projects</h1>
<p>Compare approved models by battery capacity, mounting height and operating range.</p>
<a href="/products/sl-40">View the SL-40 specification</a>
</main>
This example shows the content boundary, not a complete page implementation. Static site generation builds HTML ahead of requests. Server-side rendering builds it when a request is handled. The choice depends on update frequency, freshness requirements and the existing application.
To check the fix, repeat the same tests. The exact headline and product facts must appear as readable HTML in the response. The page must work in a fresh session, keep its interactive controls, and show the correct product revision. The team then checks the relevant Google inspection result and records whether it reflects the new release.
A live test does not show that Google has updated its index. Compare it with the indexed report in Search Console's URL Inspection tool. Keep indexing status and answer citations outside the rendering ticket's acceptance criteria.
Initial HTML: common questions
Should we remove JavaScript from the website?
No. Use it for useful interaction. The question is whether key public facts require a fragile or unsupported execution path, not whether JavaScript exists.
Does a page-source check cover every crawler?
No. It checks the response you received. Different tools have different rendering behavior and request conditions. Verify the platforms that matter to your buyers separately.
What if content appears only after opening a tab?
Check whether the content already exists in readable HTML or is fetched only after the click. Keep important product facts available without requiring an interaction, then test the chosen design.
This is part of the findability review in Semanta's service-page audit framework. When a redesign separates core content from the initial response, bring a representative page and its content source to discuss a focused technical review.