What a website says and what a visitor sees

Field notes · September 29, 2026 · 6 min read

Two readings of the same page

This year we read the websites of 195 Colorado small businesses twice. The first reading was the cheap one: a program requested each page and read the HTML the server sent back, the same way most automated tools do. The second reading opened each page in a real browser at desktop size, 1366 by 900 pixels, and looked at what the browser actually put on the screen.

The first reading produced 670 findings. Once the rendered pages were visible, 103 of them were withdrawn. That is 15.4 percent. These were not gaps the fetch had failed to fill in. They were statements about the page that the page, as a visitor sees it, did not support.

The error ran the other way too. The browser surfaced 156 findings that the fetch never saw at all. So the served HTML was not simply a thinner version of the real page, missing a few details. It was a different document. Some of what it said was not true of the page a customer sees, and some of what a customer sees was not in it.

That result is about method, not about any one business. It says something plain about how websites work now, and it matters to owners because people are no longer the only readers of their sites.

The page is built after it arrives

When a browser loads a page, the HTML is the starting point, not the finished product. The browser turns that HTML into a live structure in memory, then runs the scripts the page asks for, and those scripts are free to add, remove or rewrite what is there. Mozilla's developer documentation puts it this way:

Some sites go further and build most of the page in the browser. Google's web.dev guide describes the approach directly: "Client-side rendering means rendering pages directly in the browser with JavaScript." A menu, a list of services, a set of reviews, a contact block: any of these can arrive as instructions rather than as text.

A program that stops at the HTML reads the instructions and never sees the result. A person with a browser sees only the result and never the instructions. Both are reading the same address. They are not reading the same page.

Search engines render, on their own schedule

Google has written down how it handles this. Its Search Central documentation says: "Google processes JavaScript web apps in three main phases: Crawling, Rendering, Indexing." The rendering step happens in a queue. In Google's words:

The same page is blunt about what counts: "If the content isn't visible in the rendered HTML, Google won't be able to index it." Google, in other words, runs a browser of its own and indexes what that browser produces. That is close to what a customer sees, but it is still Google's render, done when Google's resources allow, not a customer's visit.

Many AI crawlers read the source

AI assistants are a newer set of readers, and the evidence so far points toward the cheap reading, not the browser. In December 2024 Vercel published an analysis of AI crawler traffic across its network. Its conclusion:

The crawlers named in that finding include OpenAI's OAI-SearchBot, ChatGPT-User and GPTBot, Anthropic's ClaudeBot, Meta's Meta-ExternalAgent, ByteDance's Bytespider and PerplexityBot. Vercel noted that ChatGPT and Claude crawlers do fetch JavaScript files, but "they don't execute them." It also recorded two exceptions: Google's Gemini, which runs on Googlebot's infrastructure and so renders JavaScript fully, and AppleBot, which "renders JavaScript through a browser-based crawler, similar to Googlebot."

That analysis is a snapshot from one network at one point in time, and crawler behavior can change. But it describes the same split we measured. A reader that stops at the HTML is reading a different document from the one on a customer's screen, and on our Colorado set that different document was wrong about the page in 103 of 670 findings.

Why small business sites are especially exposed

Small business websites are rarely hand-written pages. They are assembled from a platform, a theme and a stack of plugins, each of which can add its own scripts. Among the Colorado sites whose platform could be identified, two thirds ran on WordPress: 130 of 194. Another 63 announced nothing identifiable and are left out of that count. Across the web as a whole, W3Techs reports that WordPress is used by 40.2 percent of all websites, as of September 29, 2026.

WordPress itself is not the point. The point is how many moving parts sit between the HTML and the finished screen. Half of the homepages we read reference more than 22 separate files. One references 224. Those counts come only from the references written into the homepage HTML, so they are a floor: files that scripts request after the page loads are not in them.

Every one of those files is a chance for the finished page to differ from the served one. A theme can hide a section on desktop. A plugin can inject a banner, a widget or a form. A script can load text from somewhere else entirely. None of that is visible to a reader that never runs the code.

Three readers, possibly three pages

For an owner, the plain version is this. The page customers see, the page a search engine indexes and the page an AI assistant reads may not be the same page. The customer's browser runs everything. Google runs a browser too, later, on its own schedule. Many AI crawlers, according to the evidence published so far, read the HTML and stop.

This used to matter less. For years the main automated reader of a small business site was a search engine, and search engines learned to render. Now some first impressions pass through assistants that summarize a business from whatever they fetched. If the hours, the services or the service area only appear after scripts run, a reader that does not run scripts may never learn them, or may learn something the visitor would not recognize.

The check is not technical. Open the site in an ordinary browser on a computer and look at what is on the screen, not at what the site builder shows in its editor. Then compare it with what the server sends before any scripts run. Most browsers will show that source with a right click and View Page Source, and Google's own guidance points site owners to its Rich Results Test and URL Inspection Tool to see the rendered HTML Google produced. Where the important facts appear only in the rendered page and not in the source, some readers are not getting them.

The lesson from reading 195 sites twice was not that one method is right and the other is wrong. It was that they are two different documents, and anyone making claims about a website, whether a person, a search engine or a program, should know which one they read.