Your FAQ Page Answers Every Question a Customer Could Ask — AI Search Still Can't See a Word of It
A Torrance HVAC contractor spent six months building out a genuinely good FAQ page. Real questions — "how much does a mini-split installation cost in the South Bay," "do I need a permit for a tankless water heater in Torrance," "how long does a full AC replacement take." Written by someone who actually knows the trade, not scraped from a content mill. The page reads well. Google indexed it. It even ranks page one for a couple of long-tail terms.
Ask ChatGPT the same questions with "near Torrance" appended, and that business doesn't exist. Ask Perplexity. Ask Google's AI Overview box sitting above the organic results. Nothing. A competitor with a worse-written, thinner FAQ page gets cited instead — sometimes a competitor two cities over with objectively less relevant content.
This isn't a content problem. The content is fine. It's a rendering problem, and it's happening on more trades websites than owners realize, because the tool that would catch it — Google Search Console — is the one tool that's blind to it.
Googlebot Renders Your JavaScript. GPTBot Mostly Doesn't.
Here's the mechanism, and it's purely technical, which is exactly why it gets missed by people who aren't building the site themselves. Most FAQ sections on trades websites are built with an accordion — click a question, the answer expands. On a WordPress site running Elementor, Divi, or a similar builder, that accordion is frequently populated by JavaScript after the page loads. The question text might be sitting in the raw HTML. The answer text often is not — it's injected into the DOM dynamically, or it's present but hidden with display: none until a click event fires, and depending on how the builder handles it, some crawlers never see it as real, indexable text at all.
Googlebot has spent over a decade building a rendering pipeline that runs a full headless Chrome instance, executes the JavaScript, waits for the DOM to settle, and then indexes what it sees. That's why Search Console shows the page as indexed and why it can still rank on Google. Google went and solved the JS problem for its own crawler years ago.
GPTBot, ClaudeBot, PerplexityBot, and Google's own AI Overview retrieval layer do not universally get that same treatment. Large language model crawlers are optimized for speed and volume across billions of pages, not deep rendering of every site's client-side JavaScript. Many of them fetch the raw HTML response and stop there. If your FAQ answer only exists after a JavaScript event fires, an LLM crawler often grabs a page that, from its perspective, has questions with no answers — or no visible FAQ content at all. It can't cite what it can't read, and it's not going to recommend a business based on a blank paragraph.
This is why a plumbing company can rank on Google and be structurally invisible to the exact answer-engine surfaces that are increasingly where "near me" searches actually start.
Why This Keeps Happening and Nobody Catches It
The failure mode compounds because every signal the business owner checks tells them everything is fine. The page loads in a browser and looks correct — the JavaScript runs, the accordion works, the text is there. Search Console shows it indexed. Even a PageSpeed report might come back reasonable if the JS is lightweight. There is no dashboard that says "GPTBot fetched this page and got 40% less content than a human visitor did." The gap is invisible unless someone actually diffs the raw server response against the rendered page — viewing source, not inspecting the live DOM.
It's made worse by how these page builders generate FAQ schema. Many plugins auto-generate FAQPage structured data pulled from a database field, while the visible HTML on the page is built by a completely separate JavaScript render path. The schema and the visible content drift out of sync — sometimes the schema references old questions that were edited months ago, sometimes it's just thinner than what a user sees. Google has already stated FAQ rich snippets require the schema to match visible page content, and AI systems doing retrieval are increasingly skeptical of structured data that doesn't correspond to something a crawler can independently verify in the actual page text. A mismatch here doesn't just cost you a rich result. It signals the kind of low-trust content that AI retrieval systems are specifically built to filter out.
None of this is a WordPress problem exclusively, but it's disproportionately a WordPress-plus-page-builder problem, because those stacks are built to prioritize visual flexibility for a human editor, not raw HTML parity for a machine reader. The trade-off was invisible for fifteen years because the only machine reader that mattered was Googlebot, and Googlebot compensated. That compensation doesn't extend to the new crawlers.
What the Fixed Version Actually Looks Like
The architecture that solves this isn't complicated, but it requires the FAQ content to exist as real, static HTML at the time any crawler — human-rendering or not — first requests the page. On a statically generated site built in Astro or Next.js, the question and answer text are compiled into the HTML at build time. The accordion's collapse-and-expand behavior is a CSS or lightweight JS layer sitting on top of content that already exists in the page source, not the mechanism that creates the content. Open the page source — not the inspector, the actual "view source" raw response — and every FAQ answer should be sitting there in plain text before a single script executes.
Second, the FAQPage schema is generated from the exact same content source as the visible text, not a separate database field maintained by hand. If the answer changes, the schema changes with it, automatically, because they're the same underlying data. There's no drift because there's no second copy to drift.
Third — and this is the part most trades sites get wrong even when the technical rendering is fixed — the questions have to be phrased the way people actually talk to an AI assistant, not the way they'd type into a Google search box. "Mini-split installation services" is search-box phrasing. "How much does it cost to install a mini-split in a South Bay condo" is how someone actually asks ChatGPT, and it's closer to how the answer engine parses intent when deciding what to cite. This is the same principle behind good home services content generally — write for the actual question, not the keyword fragment — but it matters more here because the AI is pattern-matching your answer text directly against a conversational query, not a search term.
This is also exactly the kind of foundational fix that gets baked in from day one when a site is custom-coded rather than assembled from a builder — because rendering parity between what a human sees and what a crawler retrieves isn't a plugin setting you configure later. It's an architectural decision made before the first line of content goes in.
The Test Every Owner Can Run in Thirty Seconds
Right-click your own FAQ page. Click "View Page Source." Search for the text of your first answer. If it's not there — if all you see is the question and a blank space where the answer should be — you now know exactly why ChatGPT has never heard of you, no matter how good your content is or how many five-star reviews sit on your Google profile.
Fixing content quality won't touch this problem. Fixing keywords won't touch it. The fix is structural, and it's worth a direct conversation before you spend another six months writing answers that half the internet's search surfaces can't actually read.