How modern websites are built and delivered — and what machines see of that

• HTML

  Describes content and structure.

  Headings, paragraphs, links, images, forms. The HTML standard describes how a document is turned into a tree of nodes as it is parsed — a browser sees that tree, and everything that follows works on it.

• CSS

  Determines presentation and layout.

  CSS decides how content appears arranged, visible and operable. It replaces no structural meaning: something that merely looks like a heading is none.

• JavaScript

  Adds behaviour and can change the document tree.

  Loading data, revealing elements, validating input — all normal for an interactive website. The dependency only becomes critical once commercially important information or routes exist solely along that path and the recipient in question fails to execute it.

• TypeScript

  Is a development tool, never a delivery property.

  The official TypeScript documentation describes TypeScript as JavaScript with syntax for types and states that TypeScript code converts to JavaScript, which runs anywhere JavaScript runs. So what reaches the browser is JavaScript. “We use TypeScript” therefore says something about how a project is worked on and nothing about what an address delivers.

Table scrolls sideways

Tool	What it is	Delivery paths named by its own documentation
React	Library for component-based interfaces	Documents, among other things, attaching to HTML already generated on the server, and Server Components as an execution model of its own.
Next.js	Framework built on React	Separates server and client components in the App Router. By its own account, client components together with the server payload are prerendered to HTML; on the first load that HTML shows the page without interactivity at first.
Vue / Nuxt	Component approach and the framework above it	Nuxt documents client-side rendering, universal rendering with fully generated HTML, and hybrid rendering with separate rules per route.
Svelte / SvelteKit	Component approach and the framework above it	SvelteKit documents per-route options for prerendering, server rendering and client rendering. With server rendering switched off, the documentation says an empty shell is delivered.
Angular	extensive application framework	Documents per-request server rendering, build-time prerendering and client-side rendering as three selectable modes of its server route configuration.
Astro	content-oriented framework	By its own account renders components to plain HTML and CSS by default and strips out client-side JavaScript automatically; interactivity is requested explicitly per component.
WordPress / PHP	content management system on a server-side stack	Describes templates as the building blocks of the document structure; their markup is parsed and WordPress outputs the resulting HTML for the browser. Themes, plugins and headless setups shift that picture considerably.

• Prerendered

  The page exists before anyone requests it.

  Core content is already present as HTML on retrieval. JavaScript can add controls afterwards, yet it never has to produce the content first. Angular calls this path build-time prerendering; SvelteKit lists it as a route option.

• Generated on the server

  The page is produced on request — on the server.

  Here too a meaningful document can already reach the recipient. For this model Nuxt describes a fully rendered HTML page. So dynamically generated is a separate thing from client-dependent.

• Generated in the browser

  The first request delivers a shell; the content follows.

  For this model Nuxt describes elements that only appear after the browser has downloaded and parsed the JavaScript; SvelteKit speaks of an empty shell when server rendering is switched off. For applications that can be the right call — yet for exactly this content it creates an additional dependency on the client path.

• Mixed

  Different parts of the same website take different paths.

  The realistic default. Nuxt describes hybrid rendering explicitly as separate rules per route; Angular groups server, prerendered and client generation under one heading. A services page can deliver its text directly while a scheduler, filter or configurator only becomes interactive in the browser.

The React documentation describes hydration as attaching to existing HTML that was previously rendered in a server environment; React then takes over managing that part of the document. The Next.js documentation puts the same process the other way round: hydration is React's process for attaching event handlers to the DOM, to make the static HTML interactive. Nuxt describes the same step for its universal rendering and names dynamic interfaces and page transitions as the result.

In practice: the document can be visible and readable before anything is interactive. What happens afterwards is an addition, never a creation.

By Google's own account, a page with JavaScript passes through three phases: crawling, rendering and indexing. Google queues pages returning HTTP 200 for rendering unless a robots directive forbids indexing. According to the same source a page may sit in that queue for a few seconds, though it can take longer; only once resources allow does a headless Chromium render the page and execute the JavaScript. Google then uses the rendered HTML for indexing as well.

The same document carries the sentence that matters here: server-side or pre-rendering is still a great idea, because it makes the website faster for users and crawlers — and because some bots lack the ability to run JavaScript. That is a statement about the range of recipients, never about rankings.

In its own overview OpenAI lists several separate accesses: one for appearing in ChatGPT search results, one for training generative models, one for checking pages submitted as advertisements, and one for user-initiated fetches. For the last, the same page states explicitly that it serves no automatic crawling of the web and that robots.txt rules may fail to apply to such user-initiated actions. That alone refutes the idea of one single “AI view” of a website.

The opposite direction is neither refuted nor supported. A complete rendering specification per retrieval path is absent from these documents. That is why Pixelkiez avoids the sentence “AI crawlers skip JavaScript” — it asserts something across every provider and every access that none of the sources named here says. The reverse holds just as much: content sitting in the document tree after JavaScript has run is no proof that a given system finds it there.

What remains is a procedure rather than an assertion:

• 01

  Name the provider and the access.

  Never “the AI”, but the specific access with its identifier. Only that makes it possible to open any documentation at all.

• 02

  Check the current documentation and your own rules.

  What the provider describes today, and what robots.txt and any protective systems in front of the site actually allow.

• 03

  Observe the actual retrieval.

  In the server log or with a repeatable test. An observation is bound to its date — it replaces no commitment and no commitment replaces it.

Some automation paths work through the semantics of the interface. Playwright documents addressing elements by role, label and accessible name, and describes its own checks for whether an element is visible, stable, enabled and able to receive events. The foundation for that — roles, states and accessible names — is described by the W3C accessibility group and was designed for assistive technology, never for agents.

Other paths see the page the way a person does: providers document systems that work through screenshots, mouse and keyboard. For a website that means semantic links, real buttons, labelled form fields, stable controls and an unambiguously readable success or error state form a robust foundation — a foundation, and no guarantee. Accessibility supports certain automation paths; it differs from agent compatibility.

What follows from that for the maturity stages of a website is covered at length in the article Agent readiness: can an AI use your website? — what concerns us here is only the link to delivery: whatever exists only after successful client execution exists for an agent only after that too.

The framework name fails to tell the two apart. What has to be checked is the specific route and how it actually behaves.

One precise point often gets lost here: the directive use client means something other than “there is no initial HTML”. The Next.js documentation describes it as a boundary between the server and client parts of the project and states that client components are prerendered to HTML together with the server payload; on the first load that HTML shows the page immediately, without interactivity at first. For navigations inside the running application the same source describes it differently: there, client components are rendered entirely on the client, without server-rendered HTML.

1. Are the name, service, location and core statements in the document that a direct request returns?
2. Are internal links and contact routes real links — or areas that only a script makes operable?
3. Does the project know and document which content appears only through JavaScript?
4. Does the page stay comprehensible when part of it fails to load?
5. Are controls semantically marked up and labelled, instead of merely styled to look like a button?
6. Can an unambiguous success or error be read after an important action?
7. Has the actual delivery been tested — or inferred from the framework name?

Google Search Central

Google describes the three phases of crawling, rendering and indexing, the queue ahead of rendering, and notes that some bots lack the ability to run JavaScript.

Understand the JavaScript SEO basics Retrieved 4 September 2026

React

The React documentation explains hydration as attaching React to HTML already generated on the server, and describes how React then takes over managing that part of the document.

React — hydrateRoot Retrieved 4 September 2026

Next.js

Next.js documents the split between server and client components, prerendering to HTML, the initially non-interactive first view and the different handling of later navigations.

Next.js — Server and Client Components Document dated 25 August 2026, retrieved 4 September 2026

Nuxt

Nuxt documents client-side rendering, universal rendering with fully generated HTML, and hybrid rendering with different rules per route.

Nuxt — Rendering Modes Retrieved 4 September 2026

SvelteKit

SvelteKit documents per-route options for prerendering, server rendering and client rendering, as well as the empty shell when server rendering is switched off.

SvelteKit — Page options Retrieved 4 September 2026

Angular

Angular describes server rendering, prerendering and client-side rendering as three selectable modes.

Angular — Server-side and hybrid rendering Retrieved 4 September 2026

Astro

Astro describes how components render to HTML and CSS by default, how client-side JavaScript is stripped out in the process, and how interactivity can be requested deliberately per component.

Astro — Islands architecture Retrieved 4 September 2026

TypeScript

The TypeScript project site describes TypeScript as JavaScript with syntax for types and explains that TypeScript code becomes JavaScript, which runs anywhere JavaScript runs.

TypeScript — official project site Retrieved 4 September 2026

WordPress

The WordPress documentation describes templates as part of the document structure and explains how their markup produces the HTML delivered to the browser.

WordPress — Templates Retrieved 4 September 2026

OpenAI

OpenAI distinguishes several kinds of access with different purposes and notes that robots.txt rules may fail to apply to user-initiated actions.

Overview of OpenAI Crawlers Retrieved 4 September 2026

Playwright

Playwright documents addressing elements by role, label and accessible name, as well as the checks that take place before an action.

Playwright — Locators Retrieved 4 September 2026

W3C — Web Accessibility Initiative

The W3C documentation defines roles, states and accessible names as semantics for assistive technology.

Accessible Names and Descriptions Retrieved 4 September 2026

Status of this article: 4 September 2026. Framework documentation changes with each version, and provider statements about retrieval paths can change without notice. Where this article describes a behaviour, it describes the behaviour documented on that date.