WebinsaneSEO & AI search
Most readers never run your JavaScript.
Our homepage ships as a single empty div. Here is how it still gets read.
Our homepage is, by design, a difficult thing to index. It draws itself in WebGL, scrubs through hundreds of rendered frames as you scroll, and the HTML it actually ships is a single empty <div id="root">. Everything a person reads is assembled by JavaScript after a preloader has finished.
For an experience, that is a fair trade. For visibility, it is a poor one, unless the site is planned around it. What follows is how we approached SEO for a WebGL website, and it applies to most heavy front ends: 3D configurators, scroll-driven storytelling, single-page applications.
Google is the exception, not the rule.
Googlebot renders JavaScript, eventually. Rendering is queued, though, so first-pass indexing still sees the raw HTML. And Google is not the only reader that matters any more. The fetchers behind ChatGPT, Claude and Perplexity, the agents that read a page because somebody just asked a question, mostly take the HTML as it arrives and never run a script. Link previews in Slack, WhatsApp and LinkedIn read the meta tags and nothing else. So do readers with scripts switched off, and a good deal of assistive technology on slow devices.
For every one of those readers, an unplanned WebGL homepage is an empty page. Which is a strange outcome for a studio whose line is design for agents.
Say everything in the first byte.
The first decision was to put the page’s real content into the HTML we ship. Our index.html carries the whole site as text inside a <noscript> block: the headline, the clients, the services, the purpose statement, the route to contact, in the same order the experience presents them.
Two rules keep this honest. It is the same content, not a keyword-heavy second page written for robots; showing crawlers something different from people is cloaking, and search engines are right to punish it. And it sits outside the React root, so the framework never flashes it on screen while loading and then removes it.
Describe the studio once, and point everything at it.
Rather than several loose blocks of structured data, we publish a single connected graph. The organisation is defined once, with a stable identifier, and the website, the page and the list of clients all refer back to that same identifier. Services are a catalogue of offers; expertise is a list of what the studio knows about. The articles in this journal are blog posts whose publisher is that same organisation and whose author is a person with an identifier of their own.
What we left out matters as much. There is no FAQ markup for questions that are not visible on the page. Structured data should describe what a person can actually see.
Write one title for search and another for people.
Our brand line is Design for agents. Shape intelligence. It is right for a person and close to useless for someone searching for what the studio sells. So the page title leads with the category, and the line survives intact in the social title, where the audience is a human reading a shared link. The same split runs through this journal: each headline is written to be read, and each page title is written to be found.
Speak to AI assistants directly.
We publish /llms.txt, a short plain-text account of the studio with links, and /llms-full.txt, the whole site written out at length. Our robots.txt names the AI crawlers individually, because several of them only honour rules addressed to them by name, and it allows both the agents that fetch on a person’s behalf and the crawlers that train. For a studio that sells design for agents, being the one studio they have never read would be an odd choice. Generous snippet directives let search results and AI overviews quote at a length that means something.
Give anything that should rank its own page.
A fragment like /#work is not an address a search engine can rank on its own. So when we added this journal, we did not draw the articles inside the WebGL experience. Each is generated at build time as a complete HTML page at its own address, with its own title, description, canonical URL, preview image and article markup, readable on the first byte with no JavaScript at all. The homepage links to them with ordinary anchors, and the sitemap and an RSS feed list them.
The same thinking extends to images. Work that only exists as WebGL textures is invisible to image search, so the sitemap lists the key images with titles and captions, and we enforce one canonical host with a permanent redirect from the bare domain to www.
None of this costs the experience a frame.
That is the part I would underline. The site is still a scroll-driven film; nothing about its choreography was compromised to make it readable. The words simply exist in two places: in the experience, for people who have come to look, and in plain HTML, for everyone and everything that has come to read. How the experience itself was built is in The reader holds the playhead.
Most readers never run your JavaScript. Write for them first, and the experience can be as ambitious as you like.
Asked often.
Can Google index a WebGL website?
Googlebot renders JavaScript, so it can eventually see script-built content, but many other crawlers and AI fetchers cannot. Put the page’s real text in the initial HTML, for example in a noscript block, and use static pages for content that must rank.
What is llms.txt?
A plain-text file at the root of a site that summarises it for AI assistants and links to its key content. It complements normal SEO rather than replacing it; Google Search ignores it.
Is noscript content considered cloaking?
Not when it is the same content people see in the rendered experience. Cloaking means showing crawlers different content from users.