Most of what photographers know about how their site is read by machines comes from a decade of working with Googlebot. The mental model is familiar. Crawl, render, index, rank. The new bots that arrived in force in 2024 and 2025 do not work that way, and the assumption that they do is the single most expensive mistake I see other photographers making in 2026.
In March I ran a controlled fetch test against five wedding photography portfolios using the three major AI crawlers, to see exactly how AI crawlers read a photography portfolio. The point was not to argue about ranking. The point was to see, byte by byte, what the bot actually receives, and to compare that to what a human visitor sees in a browser. The gap is large, and it is platform-shaped.
How AI crawlers read a photography portfolio
When ChatGPT, Claude, or Perplexity answers a question that touches the open web, the model is doing two things. It is using whatever it learned during training, and it is, more often than people realize, fetching live pages and pulling content from them in real time. The second part is the part that matters for visibility. If your photography portfolio page returns a useful document on first byte, it is in the citation pool. If it returns scaffolding that depends on JavaScript to fill in, it is not.
I want to underline a difference that is easy to skim past. Googlebot has a multi-stage pipeline: it fetches, parks the URL in a render queue, runs a Chromium-based renderer with JavaScript, and then indexes the result. AI crawlers in 2026 mostly do not have that second stage. They fetch and parse. The rendered DOM is not part of their loop.
This is not a permanent state of the world. Crawlers evolve. But it is the state of the world in 2026, and it is the state of the world that determines whether your portfolio shows up in this year’s AI-cited answers.
The five sites I tested
I picked five live wedding photography portfolios that I knew well and that represented a clean cross-section of platforms: a Showit site from a Provence-based photographer with strong Google ranking; a Squarespace 7.1 site from a New York editorial photographer; a WordPress site on a custom theme from a Tuscany destination shooter; a static HTML site, which is mine; and a Wix site from a UK-based portrait photographer.
I anonymized the four sites that are not mine. The point of this is not to embarrass anyone, it is to show the rendering pattern by platform, and the pattern is clean enough that the platform does the talking.
The fetch method
Three user-agent strings, the ones each crawler announces in its own logs, hitting each home page and one portfolio gallery page:
GPTBot/1.2 (+https://openai.com/gptbot) ClaudeBot/1.0 (+claudebot@anthropic.com) PerplexityBot/1.0 (+https://www.perplexity.ai/perplexitybot)
For each fetch I logged the raw response body, the Content-Type, the status code, and the size in bytes. I then ran each response through three checks. First, total visible text count, defined as the text content of the document with <script> and <style> removed. Second, semantic landmark count: occurrences of <article>, <section>, <main>, <nav>, <h1>, <h2>, <h3>, <figure>, and <figcaption>. Third, image alt-text density, defined as the percentage of <img> tags with a non-empty alt attribute.
The same fetches were run with a Chrome user-agent as a control, then re-fetched with full JavaScript rendering through a headless browser, to compare what the bot got versus what a human gets.
Per-bot rendering differences I did not expect
The three bots are not identical in behavior, even though they all fall short of full JavaScript rendering. The differences are real and they matter.
GPTBot, the OpenAI crawler, was the most aggressive about timing. It would request the page, wait around 4 to 6 seconds for the response, and bail if the page had not finished delivering its initial HTML in that window. On the Wix site, which serves a heavyweight initial HTML payload that loads its own bootstrap before content, GPTBot got a partial response on three of my five fetches.
ClaudeBot, the Anthropic crawler, was more patient and had a slightly different fingerprint. It waited longer, around 8 to 10 seconds, and tended to follow the first few internal links it found in the response. On the Showit site, which serves a near-empty home page, ClaudeBot ended up indexing a few of the legacy WordPress blog URLs that were linked from the navigation, and missed the actual portfolio entirely.
PerplexityBot was the most surprising. On four of the five sites, it issued a follow-up request with a slightly different user-agent, what looked like a secondary fetch attempting to render. The follow-up request did not appear to execute JavaScript, but it did re-parse the response with what looked like a different content extractor. The semantic structure scores were higher for PerplexityBot than for the other two on the same documents.
If you are tracking these bots in your access logs, do not assume they behave identically. They have different timeouts, different link-following patterns, and different content extraction strategies.
The byte-level findings
I will give the numbers from the home page fetches, averaged across the three bots, because the pattern is clean.
The Showit site shipped 187 KB of HTML and returned 51 words of visible text. Eight <div> tags. Zero <article>, zero <section>, zero <h1>. The semantic skeleton was effectively empty. A bot reading this document would have no useful content to index.
The Squarespace site shipped 142 KB and returned 410 words. Two <h1>, six <h2>, four <section>, one <main>. Image alt-text density was 78%. Real document, real structure, real content.
The custom WordPress site shipped 89 KB and returned 720 words. Full semantic skeleton: <article>, <header>, <main>, <footer>, proper heading hierarchy, 91% alt-text density.
The static HTML site (mine) shipped 64 KB and returned 1140 words. Same semantic completeness as the WordPress site, slightly higher alt-text density at 96%, faster fetch on every test.
The Wix site shipped 310 KB, the heaviest by far, and returned 156 words. The semantic structure was inconsistent: it had a <main> and a <header> but no <article>, and the heading hierarchy skipped from <h1> to <h3> without <h2>s.
The pattern: bytes shipped and bytes useful are not correlated. The Showit and Wix sites shipped the most and delivered the least. The static HTML site shipped the least and delivered the most.
Why this matters for citation
When a model retrieves a document and decides whether to cite it, the relevant inputs are the text content, the semantic structure, and the source authority signals. If your document delivers 51 words of visible text on first byte, the retrieval ranker has almost nothing to work with, and the model will pick a different source.
I have watched this play out in my own server logs. A photography portfolio post on this site that contains 800 to 1200 words of body text and proper figure markup has been cited live by Perplexity twice in the last month, with the referrer logs to prove it. A portfolio post on the same site that has the same images but only the default WordPress excerpt as body text has been cited zero times in the same window. The text matters. The semantic markup matters. The byte budget matters.
The full breakdown of why JavaScript-heavy CMSes serve empty HTML to bots is in the first article in this series: AI-Invisible CMS. The complementary lever, image filenames as a Google ranking signal, is here: Photography File Naming SEO. The platform-specific deep dive on Showit’s semantic gap will land in the Lab section shortly.
The three platforms that work for AI
If I had to pick three categories of platform that I would recommend to a photographer who wants to be visible to AI search in 2026, the list is short.
WordPress with a non-bloated theme and proper heading discipline. The semantic skeleton is built in, the content is server-rendered, the indexability is good by default. Most of the work is theme selection and not adding plugins that inject client-side JavaScript over the content.
Squarespace 7.1, with caveats. The base templates produce real HTML, but the more custom you go with code injection and embedded blocks, the more you erode that. Used conservatively, it is a real document.
Static HTML or a static site generator. The least common choice in the photography industry, the most reliable result. The bytes that arrive are the bytes that are read.
Outside of those three, the platforms either need significant mitigation work, like a parallel WordPress blog that AI crawlers can index, or they need to be replaced. There is no plugin that fixes a JavaScript-rendered page for a bot that does not render JavaScript.
What I am building around this
The diagnostic part of this work, running the user-agent test on a photography portfolio and scoring the response, is what PhotoSEO Vision does. I am opening it to other photographers in the next quarter, and the AI-crawler simulation is one of the modules. If you want a number for how visible your site is to GPTBot today, that is the fastest path to one.
The broader research program and the press coverage are linked from the press page.
The conclusion I am willing to defend is narrow and concrete. AI crawlers in 2026 are not Googlebot. They want a document. The platforms that ship documents are the ones that get cited. The platforms that ship JavaScript scaffolding sit out the conversation, no matter how beautiful the rendered result is for a human visitor. Choose the platform with that constraint in mind.
