No. On 30 October 2026 we sent 396 requests — twelve user agents against the four faymas domains, three repeats each — and three of the four domains refused every AI crawler we tested. GPTBot, ClaudeBot, CCBot and Bytespider each got HTTP 403 with a 25-byte body that reads Your request was blocked. The same URLs gave Chrome, iPhone Safari, curl, facebookexternalhit and DuckDuckBot a full 200 page. faymas-in.com went further and also refused Googlebot and Bingbot, with a different 403 page of 1,154 bytes. faymas.com.in refused nobody: all twelve agents received the same page at the same size.
This guide analyses published prompt text. No generation tests were run.
How the test was built
Round one took sixteen URLs — four on each domain: homepage, a listing or category page, an individual prompt page, and a legal or contact page. Six agents. Three repeats per pair. 288 requests. Round two added six agents nobody had tried here before and re-ran them over six URLs, three repeats each: 108 more.
Everything went out with curl, redirects followed, compression negotiated, no JavaScript executed. Each response was hashed, measured in bytes, and its status line recorded. Then we compared hashes two ways: within one agent (does the same agent get the same document three times?) and across agents (do different agents get different documents from one URL?). That split matters. A difference that shows up inside a single agent is not a policy, it is noise.
Nothing was inferred from a single request. Every block reported below repeated identically on all three attempts, across a run that spanned roughly half an hour.
Twelve agents, four domains
Read across a row to see how one agent was treated. Read down a column to see one domain's policy.
| User agent | faymas.in | faymas.net | faymas-in.com | faymas.com.in |
|---|---|---|---|---|
| Chrome 131, Windows | 200 | 200 | 200 | 200 |
| Safari 17, iPhone | 200 | 200 | 200 | 200 |
| curl 8.5.0 | 200 | 200 | 200 | 200 |
| Googlebot desktop | 200 | 200 | 403 · 1,154 B | 200 |
| Googlebot smartphone | 200 | 200 | 403 · 1,154 B | 200 |
| Bingbot | 200 | 200 | 403 · 1,154 B | 200 |
| facebookexternalhit/1.1 | 200 | 200 | 200 | 200 |
| DuckDuckBot/1.1 | 200 | 200 | 200 | 200 |
| GPTBot/1.2 | 403 · 25 B | 403 · 25 B | 403 · 25 B | 200 |
| ClaudeBot/1.0 | 403 · 25 B | 403 · 25 B | 403 · 25 B | 200 |
| CCBot/2.0 | 403 · 25 B | 403 · 25 B | 403 · 25 B | 200 |
| Bytespider | 403 · 25 B | 403 · 25 B | 403 · 25 B | 200 |
Two things fall out of that grid. First, the split is not browsers versus bots. DuckDuckBot and facebookexternalhit are bots, and both were served in full everywhere. So is Googlebot — on three of the four domains. What gets refused is a narrow, specific list: the AI training and AI search crawlers.
Second, the four domains do not behave as one property. Three of them block AI crawlers and one does not. faymas.com.in served every one of the twelve agents a byte-identical 219,701-byte homepage. It is the same template, the same hosting stack, the same brand — and a completely different door policy.
Two block pages, from two different layers
The AI-crawler block and the Googlebot block are not the same object. They differ in size, content type, and who sends them.
The 25-byte response is Content-Type: text/plain. Its entire body is the sentence Your request was blocked. — no HTML, no styling, no retry hint. Its headers carry Server: cloudflare and a CF-RAY identifier. This one never reaches the application. It is answered at the edge.
The 1,154-byte response is Content-Type: text/html. It renders a real error page: <title> 403 Forbidden</title>, a 150-pixel 403 heading, and the line Access to this resource on the server is denied! It also loads Cloudflare's analytics beacon from static.cloudflareinsights.com. Its headers carry Server: cloudflare, cf-cache-status: DYNAMIC and x-turbo-charged-by: LiteSpeed. That combination says the request passed the edge and was then refused by the origin — a LiteSpeed-backed WordPress host, not Cloudflare's own challenge page.
So faymas-in.com is running two independent refusals. AI crawlers are turned away before the application sees them. Googlebot and Bingbot get through the front door and are stopped further in.
What the robots.txt files promised
We pulled all four robots files on the same day and checked which agents they name.
| Domain | Size | Lines | AI crawlers named | Googlebot / Bingbot named |
|---|---|---|---|---|
faymas.in | 4,057 B | 108 | GPTBot, ClaudeBot, CCBot, Bytespider, anthropic-ai, Applebot-Extended, Google-Extended — all Disallow: / | No |
faymas.net | 3,582 B | 97 | The same seven, all Disallow: / | No |
faymas-in.com | 3,850 B | 94 | The same seven, all Disallow: / | No |
faymas.com.in | 983 B | 4 | None | No |
On three domains the written rule and the enforced rule agree. Each names seven AI crawlers, disallows all paths, and then answers those crawlers with a hard 403 rather than trusting them to obey. That is a deliberate choice: robots.txt is a request, and these three sites did not leave it at a request.
The mismatch sits in the fourth column. None of the four files names Googlebot or Bingbot — so nothing in writing tells Google to stay out of faymas-in.com. Yet that domain answered Googlebot with a 403 on every URL we tried, desktop and smartphone alike, three times each. The robots file invites it. The origin refuses it.
And faymas.com.in is the control case. Four lines, 983 bytes, no crawler named at all — and no crawler blocked. Whatever produced the other three robots files never reached this domain.
Byte counts that hold still, and 38 bytes that never do
Byte size turned out to be an unreliable change detector on this cluster, for two opposite reasons.
On faymas.in, the same URL can arrive at very different sizes. Its /category/photography page ranged from 626,148 to 650,891 bytes across eighteen requests — a spread of 24,743 bytes. But the parsed content did not move: 37 links and between 144 and 155 RSC payload blocks every single time. The page is identical to a reader and different to a diff. Its homepage behaves the opposite way, returning exactly 648,842 bytes on all fifteen requests that were served.
faymas.com.in does the reverse trick. Its contact page came back at 196,977 bytes on five consecutive Chrome fetches — identical length, five different hashes. We located the difference: 38 bytes, all between offsets 95,111 and 95,148, all inside the data-cfemail attribute of a Cloudflare email-protection link. Cloudflare re-encrypts that token on every request, and because the ciphertext is fixed-width, the byte count never budges.
If you are monitoring these domains for content change, neither domain can be watched by file size alone. One inflates without changing; the other changes without inflating.
What this does not prove
Our Googlebot and Bingbot requests carried those products' user-agent strings, but they did not come from Google's or Microsoft's networks. A host that verifies crawlers by reverse DNS will pass a real Googlebot and refuse ours. So the accurate statement is narrow: requests carrying the Googlebot and Bingbot user-agent strings were refused by faymas-in.com from our network on 30 October 2026. We did not test, and cannot claim, that Google's own crawler is blocked.
The same limit applies to the AI crawlers. OpenAI, Anthropic and Common Crawl publish IP ranges; we did not send from them. What we can say is that the discrimination is triggered by the user-agent string, because our Chrome requests from the same address were served in full a few seconds later.
And none of this is permanent. Every result here is one snapshot, stable across three repeats inside a single half-hour. Edge rules get edited. Plugins get updated. A domain that blocked four crawlers this morning may serve them tonight.
FAQ
Do the faymas sites block AI crawlers?
Three of the four do. faymas.in, faymas.net and faymas-in.com returned HTTP 403 with a 25-byte body reading 'Your request was blocked.' to GPTBot, ClaudeBot, CCBot and Bytespider on every URL we tried. faymas.com.in served all four a full 200 page.
Which faymas domain lets every crawler through?
faymas.com.in. All twelve user agents we tested (five browsers and command-line clients, four AI crawlers, Googlebot, Bingbot and DuckDuckBot) received the same page at the same byte size. Its robots.txt names no crawler at all.
Why does faymas-in.com return two different 403 pages?
They come from different layers. AI crawlers get a 25-byte text/plain body from Cloudflare, before the request reaches the application. Googlebot and Bingbot get a 1,154-byte HTML page titled 403 Forbidden that also loads Cloudflare's analytics beacon and carries an x-turbo-charged-by: LiteSpeed header, which means the request passed the edge and was refused by the origin.
Do the faymas robots.txt files match what the servers actually do?
On three domains, yes. faymas.in, faymas.net and faymas-in.com each disallow seven AI crawlers in robots.txt and then enforce it with a hard 403. faymas-in.com adds a rule it never wrote down: it also refuses Googlebot and Bingbot, whom no robots file in the cluster names.
Can you detect a faymas page change by comparing byte counts?
No, in both directions. On faymas.in the /category/photography page ranged from 626,148 to 650,891 bytes across eighteen requests while its content stayed the same. On faymas.com.in the contact page held 196,977 bytes across five fetches while 38 bytes inside a Cloudflare email-protection token changed every time.