Collection AI Readability

Dear Sitejet team,

we have noticed that the content within the Collections feature currently cannot be read by AI tools, as it is dynamically loaded. For our clients, the visibility of their Collections content is extremely important.

We would like to know if there are any plans to update the Collections feature so that its content can be indexed and/or read by AI tools in the future. Improved visibility would be a major benefit for our clients and help them stay competitive as AI continues to evolve.

Dear community,

is anyone else facing this issue? Has anyone discovered any effective workarounds? We attempted to separate the blog from our main Sitejet website by hosting it on a subdomain with WordPress. However, this approach feels quite inefficient, as it has doubled our website maintenance efforts.

Thank you in advance for your feedback!

Hey there,

Currently, the collection entries are loaded after the page is rendered. The AI does not execute the Javascript, it just fetches the webpage and reads it (before the data loads).

AI tools should be able to render Javascript soon like all search engines do nowadays. Even our importer does that. With the rise of tools like PAL that generate React-websites that render completely in Javascript, this will be even more pressing in the future.

This has been discussed internally a few months ago and we are monitoring the situation at the moment. You could generate a feature request in this community already, if you like as well.

Hey @eevee,

We’ve run into the same thing too! Since the dynamic loading in Collections makes it hard for crawlers and AI tools to read the content, we decided to move our blog to a separate subdomain — but instead of WordPress, we built it as a static site.

That way, everything is pre-rendered as HTML and fully visible to search engines and AI tools. It’s been working great for visibility and feels lighter to maintain than running WordPress alongside Sitejet.

Would definitely love to see Sitejet make the Collections feature more indexable in the future though — that would make things much easier for everyone!

How’s your experience been managing updates between your main site and the WordPress blog?

Hey @Andre ,

it has been some time since I created this topic. I was wondering if you guys have figured something out by now, as you mentioned you were monitoring the situation?

Unfortunately, the urgency of this issue has only grown. AI and AI-powered search is becoming increasingly important and websites that are not AI-readable are at a real risk of falling behind the competition.

For agencies like ours, a blog or collection that cannot be crawled and read by AI tools is essentially invisible in the emerging AI search landscape. This directly impacts our clients ability to stay competitive, attract new patients/customers, and rank for relevant topics.

The workarounds mentioned in this thread, such as moving the blog to a static subdomain or WordPress, are functional but add significant maintenance overhead and feel like a step backward for an otherwise streamlined platform like Sitejet.

Is there any update on a roadmap item for server-side rendering or static HTML output for Collections? Even a basic pre-rendering option would make a significant difference for us and, I imagine, for many other agencies using Sitejet.

Thanks for keeping this on your radar, and I hope it can be elevated to a higher priority given how fast the AI search is evolving.

Following this topic, it’s really important.

The idea to move the blog to Wordpress when building Sitejet websites is definitely no option. Many (if not most) of us left Wordpress behind and chose Sitejet over it for good reasons.

A pagebuilder needs to write KI readable code. Otherwise the tool will lose its relevance and people will move over to different systems like Squarespace etc.

I will move this topic to the feature request section so this gets picked up in the next product meeting.

Hey Andre,

Please let us know after the product meeting. This is a really important issue.

I looked into whether AI bots can render JavaScript, and these are the answers I found, but they didn’t fully clarify the issue for me. What do you or the product team know about this?

Thanks.

Claude: Short answer: no — not the crawlers that matter most for SEO, anyway.

AI crawlers (GPTBot, ClaudeBot, PerplexityBot, etc.) do not render JavaScript. They send a plain HTTP request, grab whatever HTML comes back in that first response, and move on. No headless browser, no waiting for React/Vue/Angular to hydrate, no executing scripts — a large-scale analysis of major AI crawlers found none of them currently render JavaScript. This holds for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, and others, as of mid-2026.

Googlebot is the exception, not the rule. Google uses a headless Chrome-based engine that actually executes JavaScript and indexes the fully rendered page, which is why a client-rendered site can rank fine on Google while being invisible to AI answer engines — the same page can be a Google success and an AI ghost at the same time. The only AI-adjacent exception is Google Gemini, which piggybacks on Googlebot’s rendering infrastructure.

Why this matters for your work specifically: if any of your client sites (readyclean.hu, Hume Executive, the coaching site) load key content — pricing, service descriptions, CTAs, FAQ text — via client-side JavaScript rather than having it baked into the initial HTML, that content is simply invisible to ChatGPT, Claude, and Perplexity when they cite or answer questions about the business. The test is simple: view the page source (not the rendered DOM) — if your real text isn’t there and you just see a script tag and an empty div, AI crawlers see nothing.

The fix, if it applies: server-side rendering or static generation so critical text is present in the raw HTML response, not injected after the fact.

Want me to check whether any of the sites you work on have this problem? I can fetch the raw source and see what’s actually there versus what a browser renders.