Making 3D Websites Readable to Search and AI Crawlers: Prerendering, Bot Policy, and Structured Data

A Client-Rendered 3D Site Shows Crawlers an Empty Shell

The picture on a 3D or single-page site is assembled by the browser after JavaScript loads, so the raw HTML a crawler fetches first is often an empty container with no h1, paragraphs, or body text. Google processes pages in three stages, crawling, rendering, and indexing, and only content visible after rendering can be indexed. Rendering runs only when resources allow and not every bot executes JavaScript, so the documentation still recommends server-side rendering or prerendering (Google Search Central, JavaScript SEO basics).

POLISH's previous website was a single-page app built with Vite, and it gives a before-and-after view of this problem. Before prerendering, the raw HTML of the home page was 730 bytes. After prerendering it was 39,516 bytes, and the picture did not change: verification found 0 hydration errors and 0 broken images.

The approach was to keep the framework and leave the components alone. The route configuration is shared by the browser and the prerenderer, and the build gained one step that renders each route to static HTML. Every use of a browser API was reviewed first, and all sat inside effects, so no logic needed to change. Each page has one h1 with the direct answer right after it, plus its own title, description, canonical, and og tags. When 3D website development runs into this problem, switching frameworks is not always required.

Prerendering is not finished once pages render: the script handles title, canonical, hreflang, and og tags, while the lang attribute of the html element, og:image, and 404 responses need separate work. Case pages show text early thanks to prerendering, and the Largest Contentful Paint (LCP) rated good; the measurement is a local lab run simulating slow 4G and a 412×823 phone viewport, 3 runs per page, and is not a PageSpeed Insights figure. Loading performance is covered in web 3D performance engineering.

Ways to Get Text Into the Source Without Changing Frameworks

Server Content in an Initial Overlay

A public-sector information site built with Next.js gives every data level its own URL. The server generates the text, metadata, and JSON-LD; once the interactive version opens the same target, the text layer is removed. The text layer must stay hidden until hydration finishes, or a phone refresh first flashes a full text list; it is shown only when 3D fails to load or does not take over before a timeout. Text components inside the 3D scene use div, so each page keeps one h1.

Visually Hidden or Low-Opacity Text

In 2026-06, the AEO handover document for Cooking Monsters suggested placing the text below the first screen or in a collapsible drawer, not using display:none, with very low opacity only as a fallback. That was a recommendation, not a measurement. The approach adopted: on 2026-08-03 the home page was split into server and client components, and service cards and FAQ were served from the back-office database, still using incremental static regeneration (ISR).

How to Choose

The choice follows the team's experience and is not a conclusion drawn from official documentation.

The overlay and the visually hidden approaches both show crawlers text that is hidden from people. The content must match what users see, and when 3D fails, users must actually be able to read it. Acceptance is a script that fetches the HTML without JavaScript and verifies, page by page, the h1, title, canonical, and structured data.

AI Crawlers Are Not One Thing: Search Indexing, Training, and User-Triggered Fetches

Official documents sort crawlers into three kinds: search indexing, training, and user-triggered fetches. For the user-triggered ChatGPT-User and Perplexity-User, the documents say robots.txt rules may not apply or are generally not followed. Google-Extended is a standalone token with no user agent of its own; it controls whether content is used to train Gemini models and for grounding in Gemini Apps and Vertex AI, and does not affect Google Search inclusion or ranking. The table follows each vendor's documents, checked on 2026-11-05.

robots.txt is a standard, but not access control: RFC 9309 is a Proposed Standard, section 1 explains that its rules are not access authorization, and section 3 explains that the protocol is no substitute for effective content security (Koster et al., 2022). So the setup has two layers: well-behaved crawlers are grouped in robots.txt, and requests that ignore it are refused at the server by user agent. Matching must use whole words, or it blocks user-triggered fetches such as ChatGPT-User and Claude-User.

Whether Content Is Used for Training Is a Business Decision

Search crawlers and training crawlers can be handled separately, so it is not an either-or choice. According to the documents above, different crawlers handle the two, and closing only the training ones leaves the search crawlers unaffected. Whether to close those crawlers depends on whether the content can be licensed and on the position taken toward training. That is a business decision, not a technical default.

POLISH built this split for the public information site of a public-sector organization: the client asked to keep AI crawlers from using the content, and the site still had to be found by Google and the major AI assistants. The robots.txt has three groups: the default group; search and assistant crawlers (Googlebot, OAI-SearchBot, and others), open to the site's content; and training-only crawlers (GPTBot, ClaudeBot, and others), disallowed across the whole site. Requests that ignore robots.txt are refused at the server by user agent. A named crawler no longer consults the default group, so the search group repeats the paths that stay closed, such as the API.

Google-Extended is the hardest to place: it governs Gemini training and grounding at once, yet does not affect Google Search inclusion or ranking. That site put Google-Extended in the open group; where it belongs depends on the client's position on training.

POLISH's own site went the opposite way and keeps everything allowed: the content is marketing and case studies, no evidence was found that blocking training crawlers affects being cited, and allowing training is a business decision. With the same classification, the two sites chose opposite answers, and the difference lies in whether the content can be licensed. AI adoption and data governance starts from that decision.

Structured Data: What to Add and What to Leave Out

More structured data is not better. What to add and what to skip follows the actual feedback in Search Console. A public-sector information site added the following:

• Data pages use WebPage, with dateModified set to the date the data was obtained.
• List pages use CollectionPage with ItemList.
• Event pages use Event, with dates taken from the back end.
• Videos and data pages link to each other, and VideoObject states about.

Three things were left out on purpose: SearchAction on WebSite, because the on-site search has no URL; FAQPage, because the site has no real Q&A page; and sameAs, because there are no official social links. Event data also needs performer and offers, which Search Console flags when missing. For a service provider's own site, Organization and Article JSON-LD come before FAQPage.

Google's update history states that FAQ rich results stopped appearing in Google Search on 2026-05-07, and that the help documentation was removed on 2026-06-15 (Google Search Central, Latest documentation updates). With no real Q&A page on the site, no FAQ markup is added.

A Test: AI Overviews Rarely Appear for Traditional Chinese Buyer Queries

On 2026-11-04, POLISH tested 20 buyer queries on Google (hl=zh-TW, gl=tw), looking at the first page of organic results and using a regex to detect AI Overviews: 3 queries showed one, and among the 15 Traditional Chinese buyer queries only 1 did. For 3D-related buyer terms, the first page had almost no Taiwan-based providers, which may be an opportunity. This is a single snapshot from one location, and it is for reference only.

Google's explanation is that a page must already be indexed and eligible to appear in Search with a snippet to be a cited source in AI Overviews and AI Mode, no AI-specific markup or file is needed, and meeting the conditions does not guarantee display (Google Search Central, AI features documentation). So budget should not go to AI markup first: publish the pages that answer buyer questions first, with a direct answer paragraph and first-party data.

The top finding of an audit is often not missing content but that the pages which best answer buyer questions are set to noindex, or have no inbound links at all. Fixing that comes before adding new articles.

What the Research Says: Cited Sources and Statistics

The GEO (Generative Engine Optimization) paper tested 9 optimization methods with GEO-bench and Perplexity.ai. Both citing sources and adding statistics improved visibility in generative engines, and the abstract reports gains of up to 40%; but the effect varied with the source's rank, and the source ranked first actually declined (Aggarwal et al., 2024).

The paper's limits belong with it. The test environments were the authors' own generative engine and Perplexity.ai, not the live rankings of Google or ChatGPT. The paper's text and tables disagree in places, and most percentages would need recomputing from the absolute scores in the original tables, so this article cites only the abstract's 40%. How a generative engine retrieves content before answering is covered in what retrieval-augmented generation (RAG) is.

Every FAQ Line Is a Public Claim, So Check Each One Before Launch

An FAQ written for search and AI engines is a set of public claims, line by line. The FAQ for the Cooking Monsters AI menu platform comes with a handover document that carries a column of facts to confirm: which language model the menu connects to, where the data comes from, and how fees are calculated. On 2026-07-02 the content was aligned item by item with the actual product, and on 2026-08-03 the FAQ moved to the back-office database, so a product change does not leave the page on the old wording.

What to Check Before a Redesign

Before a redesign or SEO work, the items below come before new articles; the same items also work as questions when evaluating a vendor, and how to evaluate a software vendor covers the wider criteria.

• Index scope: check with a Google site: query; old project subdomains and back-office login pages are often indexed and dilute the main site. Back-office subdomains should answer with X-Robots-Tag: noindex, since a Disallow in robots.txt only blocks crawling, not indexing.
• Status codes: a random URL that returns 200 with home page content may look like a valid page to a search engine. Missing files and nonexistent URLs should return 404; on a 3D project, a missing file under /assets/ that falls through to the fallback turns the model into an HTML page answering 200, and three.js reports a misleading error.
• Brand collision: when a brand name overlaps with a common word or a foreign name, search results are easily filled by others. The direction for a fix is the full legal name, the business registration number, consistent sameAs links, and an entity page.

When This Does Not Fit

• Content that is not public, such as an internal system. Such a site needs access control, not search visibility.
• Sites that run only paid ads and do not rely on organic traffic. Prerendering and crawler routing bring limited benefit.
• Expecting markup alone to earn AI citations. Without content, markup does nothing, and Google states that no AI-specific markup or file is needed.

What to Prepare

Before a conversation, prepare three things: the URL of the existing website, Search Console access, and a decision on whether content may be used for training. The third is a business decision; if it is still open, the discussion can start anyway, with crawler routing designed as search and assistants open and training pending. Talk to the development team about the visibility of an existing site.