Technical foundations
Building Pages Search Engines and AI Tools Can Read
Why content in the initial HTML outperforms content assembled by script, for both Google and AI assistants.
Part of the Real Estate Website Rebuilds guide · Last reviewed 2026-08-09
A page a search engine can read is one whose meaningful content is present in the HTML the server returns, before any JavaScript runs. Google processes pages in three phases: crawling, rendering, and indexing. Crawling reads what the server sent. Rendering runs JavaScript afterwards from a queue that Google says a page may sit in for a few seconds or longer. Google still recommends server-side or pre-rendering because it makes a site faster for users and crawlers and because, in its own words, not all bots can run JavaScript. For real estate sites, where listings and neighbourhood content usually arrive by widget, this is the difference between a page with substance and a page with a loading state.
Key takeaways
- Google's three phases are crawling, rendering, and indexing, and rendering happens from a queue.
- Google's own wording is that a page may stay in the rendering queue for a few seconds, but it can take longer.
- Google recommends server-side or pre-rendering because not all bots can run JavaScript.
- AI assistant retrieval is generally less capable than Google's renderer, so JavaScript-only content is a larger problem there.
- An IDX widget can stay, provided the page around it has real text that stands on its own.
The three phases, and where content goes missing
Google documents its pipeline as crawling, then rendering, then indexing. In crawling, Googlebot fetches the address and parses the returned HTML for links and content. Pages returning a 200 status are queued for rendering, where a headless Chromium executes the JavaScript. Only then is the rendered result indexed.
The gap is the queue. Google's phrasing is that a page "may stay on this queue for a few seconds, but it can take longer than that. Once Google's resources allow, a headless Chromium renders the page and executes the JavaScript." Content in the initial HTML is available in the first phase. Content added by script waits, and how long it waits is not under your control.
The IDX problem, stated fairly
Real estate sites have a specific version of this because listing data is usually delivered through an embedded IDX widget, which fetches and renders client-side by design. Sometimes neighbourhood pages and even the agent's biography come through the same system.
The widget is not the enemy and removing it is usually neither possible nor desirable. The practical approach is to stop the widget being the only thing on the page. A neighbourhood page that consists of a heading and a listings widget has no content of its own. The same page with several paragraphs about the area, written by someone who works it, is a real page that happens to also show live listings.
That framing keeps the useful part of the widget while giving the page something that exists during crawling.
Why this matters more for AI assistants than for Google
Google's renderer is comparatively capable, so a JavaScript-heavy page will often be indexed eventually. The retrieval systems behind AI assistants are generally less so, and Google's own guidance acknowledges the wider point that not all bots can run JavaScript.
This creates an asymmetry worth planning around. A site that depends on rendering may be acceptable for Google and close to invisible to an assistant fetching the page to answer a question. Since the fix is the same in both cases, putting the content in the HTML, there is no tradeoff to weigh.
Checking your own pages
Two checks, neither requiring special tools. First, view the page source and search for a sentence you can see on screen. If it is absent, that sentence is not there during crawling.
Second, use the URL Inspection tool in Search Console for that page and look at the rendered HTML and screenshot Google reports. That shows what Google ended up with after rendering, which may differ from both the source and what you see in your browser.
Run both on the pages that matter most: your biography, your main service pages, and any neighbourhood page you expect to rank. A discrepancy on those is worth more attention than a perfect score on pages nobody searches for.
What to put in the HTML
The content worth guaranteeing is the content someone would quote back to you. Concretely, for a real estate site:
- The agent or brokerage name, licence jurisdiction, and the areas actually worked, written as sentences.
- The body text of every neighbourhood, service, and guide page, independent of any embedded widget.
- Headings that state what the section covers, so structure is visible without running scripts.
- Descriptive link text between pages, since crawling parses the returned HTML for links.
- Contact details as text rather than only inside an image or a script-driven component.
| Where the content is | Seen during crawling | Practical risk |
|---|---|---|
| In the HTML the server returns | Yes | Low |
| Added by JavaScript after load | No, waits for rendering | Delayed indexing, weaker AI retrieval |
| Inside an embedded third-party widget | No | Page may have no content of its own |
| Text baked into an image | No | Not readable as text at all |
Frequently asked questions
Does Google index JavaScript content or not?
It does, but in a later phase. Google crawls first and reads the returned HTML, then queues the page for rendering where JavaScript executes, then indexes the result. Google says a page may stay in that queue for a few seconds or longer. So JavaScript content is usually indexed eventually, while content in the initial HTML is available immediately and does not depend on the queue.
Do I have to remove my IDX widget to be readable?
No. The goal is that the page has real content of its own around the widget, not that the widget disappears. A neighbourhood page with several paragraphs written by someone who knows the area, plus a live listings widget, works for both readers and crawlers. A page that is only a widget has nothing to offer when the widget has not loaded.
How do I see what Google actually sees on my page?
Use the URL Inspection tool in Search Console and view the rendered HTML and screenshot it reports for that address. That reflects what Google ended up with after rendering. Pair it with a plain view-source check, which shows what existed before any JavaScript ran. The difference between the two is exactly the content that depends on rendering.
Is server-side rendering necessary for a real estate website?
Not strictly necessary, but Google recommends server-side or pre-rendering, saying it makes the site faster for users and crawlers and that not all bots can run JavaScript. For a site where listings are inherently dynamic, a practical middle path is server-rendering the written content and letting the live listing feed load client-side.
Will fixing this help with ChatGPT and other AI assistants?
It is a prerequisite rather than a guarantee. Retrieval behind AI assistants is generally less capable at running JavaScript than Google's renderer, so content only present after rendering is at greater risk of being missed entirely. Putting it in the HTML removes that risk. Whether an assistant then cites you depends on whether the page answers the question being asked.
Related pages in this guide
Related reading
Sources
Every claim on this page that could be checked against a primary source is linked below. Where something is not publicly documented by a vendor, the page says so rather than filling the gap with an estimate.
- JavaScript SEO basics (Google Search Central)
- AI features and your website (Google Search Central)