The Invisible Wall: How Hostinger's Hidden Bot Protection Is Silently Erasing Websites from the AI Internet

The Invisible Wall: How Hostinger’s Hidden Bot Protection Is Silently Erasing Websites from the AI Internet

An Investigative Technical Report

Something Is Very Wrong

Imagine you’ve done everything right. Your website is live, your content is original, your SEO is dialed in…you’ve even gone the extra mile—creating an llms.txt file, setting generous meta robots directives, and explicitly welcoming AI crawlers in your robots.txt. You’ve read the articles about AI-powered search engines like ChatGPT, Perplexity, and Claude becoming the new front page of the internet, and you’ve prepared accordingly.

Then you ask one of these AI assistants about your business…and it has no idea you exist.

Not because you blocked it, not because your content is thin, not because of anything you did at all. Your hosting provider—without telling you, without giving you a toggle, and without any visible trace in your control panel—has erected an invisible wall between your website and the AI-powered internet. Every time an AI crawler knocks on your door, it doesn’t get your carefully crafted content. It gets this:

“Verifying that you are not a robot…”

This is the story of how Hostinger’s undocumented, unconfigurable infrastructure-level bot protection is silently cutting off an unknown number of websites from AI answer engines…and how the affected customers are the last ones to find out.

The Case That Started It All

The investigation began with a straightforward client engagement. A digital marketing agency (we’ll call them the client) noticed that AI assistants couldn’t access or cite their website. The site is hosted on Hostinger’s Cloud Startup plan, a popular, affordable tier marketed to growing businesses and agencies.

The symptoms were specific and reproducible: when ChatGPT, Claude, or Perplexity attempted to fetch any page on the client’s site, they received a bot verification challenge page instead of content. The site was, for all practical purposes, invisible to the AI internet.

What followed was a systematic, exhaustive elimination of every possible client-side cause.

Everything the Client Did Right

Every layer of the stack was examined and cleared:

WordPress Configuration. The robots.txt file was standard WordPress—no blocks on any crawler; meta robots tags were set to follow, index with unlimited snippet lengths; rank Math had properly generated an llms.txt file exposing the full site structure to AI crawlers; all 13 active plugins and 3 must-use plugins were individually reviewed with none implementing bot protection or challenge pages.

Server Configuration. The .htaccess file was clean, only WP Rocket caching rules and standard WordPress rewrites. No IP blocking, no user-agent filtering, no custom challenge logic.

Hostinger CDN/WAF. Hostinger’s control panel includes an “AI Audit” feature within the CDN settings that allows customers to manage how AI bots are handled. Every AI bot was explicitly set to Allow. The dashboard reported 116 requests from AI crawlers, all marked as “allowed,” zero blocked. The CDN’s Web Application Firewall had no rules targeting AI crawlers. By every metric the control panel offered, AI bots were welcome. As we’d later discover, this data was telling a very incomplete story.

DNS and Network Path. The domain resolves to Hostinger IP addresses. There is no Cloudflare proxy or external WAF. With Hostinger’s CDN active (as it was for this site), responses include a server: hcdn header, confirming that Hostinger’s CDN proxy handles all incoming requests. Direct requests to these IPs with the correct Host header return no response, indicating the origin server is not directly reachable from outside.

External Verification. Here’s where it gets interesting. Using curl with AI user-agent strings from residential and independent VPS IP addresses returned HTTP 200 with full page content. Google’s Rich Results Test fetched the site fine. The web-based testing tool ReqBin retrieved complete content without issue.

The site was accessible. Just not from where it mattered.

The Smoking Gun

The critical variable wasn’t the user-agent string; it was the source IP range of the request. Requests from residential IPs, general-purpose testing tools, and even an independent VPS all passed through cleanly. Requests originating from the specific datacenter IP ranges published by OpenAI, Anthropic, and Perplexity (the production infrastructure these AI services use to crawl the web) hit a challenge wall.

This is a meaningful distinction. The filtering isn’t triggered by datacenter IPs generically; it targets the known, published IP ranges associated with AI services specifically. An independent VPS using an identical AI user-agent string received full page content without challenge. Only requests from the actual AI company infrastructure were blocked.

This wasn’t a robots.txt issue. It wasn’t a plugin. It wasn’t a misconfiguration. It was targeted IP-range filtering happening at a layer the customer couldn’t see, couldn’t configure, and didn’t know existed.

Even Hostinger’s own AI support assistant, Kodee, when presented with the full diagnostic evidence, assessed the situation this way:

“The challenge is almost certainly coming from an upstream edge/security layer that’s treating headless/AI traffic as high-risk.”

And:

It “can’t be per-bot tuned on your plan.”

A caveat: Kodee is an AI chatbot, not a Hostinger engineer or official spokesperson, and its responses should be weighted accordingly. That said, its assessment is consistent with every diagnostic finding and aligns with the community evidence detailed later in this report.

Read the second quote again regardless. Hostinger’s own system is acknowledging that it’s blocking legitimate traffic the customer explicitly allowed…and that the customer has no way to fix it.

Pulling the Thread: A Pattern Emerges

Once the root cause was identified for the client’s site, the natural question became: is this an isolated case, or a systemic issue?

The answer, documented across multiple independent platforms over a span of more than eighteen months, is unambiguous. This is a known, recurring problem affecting an unknown number of Hostinger customers on Cloud Startup and similar shared hosting plans. And for many of them, the story ends badly.

WebHostingTalk — July 2025

One of the earliest and most detailed reports surfaced on WebHostingTalk, a long-established hosting industry forum where system administrators and hosting professionals have been comparing notes since the early 2000s. Multiple sites hosted on Hostinger were suddenly hit with a server-injected reCAPTCHA “Bot Verification” page on their homepages. The behavior appeared without warning and without any corresponding change in the customer’s configuration.

The thread documented that the challenge pages blocked Googlebot—not just AI crawlers, Googlebot itself—resulting in “Page with redirect” errors in Google Search Console and severe SEO damage. After persistent escalation, Hostinger support eventually admitted that their own system engineers had unilaterally enabled aggressive bot protection at the system level. The protection operates upstream of the customer’s site, CDN, and plugins. Customers on standard plans can’t disable it.

The original poster described the action as “unilateral” and called attention to the damage it caused—rankings lost, traffic destroyed, with no prior notification.

Source: WebHostingTalk Thread #1944630

LowEndTalk — July 2025

A parallel discussion on LowEndTalk, a forum frequented by technically sophisticated hosting customers, corroborated the WebHostingTalk findings. Users reported the same pattern: bot verification pages appearing on Hostinger-hosted sites, blocking legitimate crawlers, and causing cascading SEO failures. The discussion confirmed the behavior was infrastructure-level and outside customer control.

Source: LowEndTalk Discussion #207843

Reddit r/Hostinger — Late 2025

By late 2025, the problem had generated significant discussion on Reddit’s Hostinger community. One user reported pages randomly showing the bot verification screen despite having no Cloudflare Bot Fight Mode and no reCAPTCHA plugin installed. The impact was severe: Googlebot crawling broke, approximately 150 pages were affected, and at least one page dropped from first or second-page search results to being completely deindexed.

When the user contacted support, they were told the fix or settings to control the behavior were only available on VPS plans, not Cloud Startup or shared hosting. No migration assistance was offered. Another user in the same thread confirmed: “That’s been happening to me too.” The original poster ultimately migrated to AWS.

Source: Reddit — “Can someone please fix the bot verification issues”

A separate Reddit thread from mid-2024 shows users asking how to disable the robot verification entirely, indicating the problem predates the 2025 wave of reports by a significant margin.

Source: Reddit — “Disabling robot verification”

X/Twitter — January 2026

The complaints continued into 2026 on social media. A Hostinger Cloud Startup user reported that normal users—not bots, not crawlers, human visitors—were being blocked with heavy bot verification simply for visiting the site frequently. Hostinger support blamed Cloudflare, but the user correctly noted the challenge page didn’t match Cloudflare’s captcha style. Another user publicly called on Hostinger to fix the issue, reporting lost Google rankings and pointing out the volume of complaints visible with a simple web search.

Source: X/Twitter — @hello_sakin

WordPress.org Support Forums

Multiple threads on WordPress.org’s support forums describe the same symptoms from the WordPress user’s perspective: sites suddenly displaying bot verification pages with no corresponding plugin or configuration change. One thread independently identified the LiteSpeed server component as the source of the challenge message. These threads further confirm the behavior is not WordPress-specific but hosting-infrastructure-specific, though WordPress users form the bulk of affected reports, likely reflecting Hostinger’s heavy marketing toward the WordPress market.

Sources: WordPress.org — “My website showing bot verification”, WordPress.org — “My website is asking for bot verification everytime”

The Cloudflare Twist

Here’s an ironic wrinkle: some Hostinger users who placed Cloudflare in front of their sites (a logical workaround attempt) discovered that Hostinger’s bot verification page was being cached by Cloudflare’s CDN and served to all visitors. An intermittent bot challenge became a persistent site outage. One thread documented the issue affecting PDF download URLs specifically, extending the problem beyond standard page requests. The fix for the invisible wall made the wall visible to everyone.

This highlights how a verification page injected at the infrastructure level, outside the customer’s application stack, can interact unpredictably with standard web architecture in ways that amplify the original damage.

Sources: Cloudflare Community — “Bot verification page by Hostinger is being cached on Cloudflare CDN”, Cloudflare Community — Bot verification on PDF download URLs

It’s Not Just WordPress

A StackOverflow thread documents the same bot verification behavior affecting a Laravel API application on Hostinger, no WordPress involved at all. This strongly indicates that the issue is at Hostinger’s infrastructure layer, independent of any CMS, framework, or application code.

Source: StackOverflow #79647763

It’s Not Just Crawlers

A Reddit r/CloudFlare thread shows Bing’s search index displaying “Bot Verification” as the title tag for a Hostinger-hosted site—meaning Bing crawled the site, got the challenge page, and indexed that as the site’s content. When a security measure becomes your site’s title in Microsoft’s search engine, the problem has moved from “technical nuisance” to “reputational damage.”

Source: Reddit r/CloudFlare

People Are Paying Strangers to Fix This

Another interesting data point: freelancer platforms now feature paid jobs posted by site owners desperately trying to resolve the “verifying that you are not a robot” issue on their Hostinger-hosted sites. These aren’t technical professionals with the tools to diagnose an infrastructure-level block. They’re small business owners who know something is wrong and are willing to pay anyone who can make it stop.

Source: Freelancer.com — “Verifying that you are not a robot” project

The Technical Anatomy: Why This Is So Hard to Find

Understanding why this problem is so insidious, and why it took systematic diagnostic work to identify, requires examining the architecture of modern shared hosting and how AI crawlers differ from the traffic most people think about.

What We Can See — And What We Can’t

Hostinger’s infrastructure includes multiple layers of traffic processing before a request reaches a customer’s WordPress installation. Through direct testing, we were able to map part of this architecture—but only part.

What HTTP headers reveal: With the CDN active, requests to the site pass through Hostinger’s CDN proxy, which identifies itself as hcdn in the HTTP server header. The origin server behind this proxy is not directly reachable from outside; requests to the domain’s resolved IP addresses with the correct Host header (e.g., curl -sI -H "Host: [domain]" https://[IP] --insecure) return no response at all. This is not a simple SNI issue; the server was given proper identification and still refused to respond to external connections. The origin appears to be firewalled to accept connections only from Hostinger’s own CDN infrastructure, which means we cannot inspect the origin server’s software or headers from the outside.

What the control panel reveals: The CDN provides two customer-facing security features. The AI Audit lets customers allow or block specific AI crawlers by user-agent. The Security Level sets a threat-score threshold for challenging visitors, with settings ranging from “Essentially Off” to “I’m Under Attack.” In our investigation, AI Audit had every bot set to Allow (116 allowed, 0 blocked in the dashboard), and the Security Level was set to “Essentially Off.”

What’s doing the blocking: Despite both customer-facing security features being configured to allow traffic, AI crawlers from their published datacenter IP ranges still received challenge pages. The challenge is being served by a mechanism that is not represented in the CDN’s AI Audit logs, not controlled by the Security Level setting, and not visible anywhere in the customer’s control panel. It responds to the specific IP ranges associated with known AI services, not the user-agent string and not datacenter IPs generically.

The leading hypothesis—LiteSpeed’s server-level reCAPTCHA: Multiple independent reports from other Hostinger users point to LiteSpeed Web Server’s built-in reCAPTCHA protection as the specific mechanism. A Cloudflare community thread identified the challenge as “Hostinger’s DDoS protection mechanism, which uses LiteSpeed reCAPTCHA.” A WordPress.org support thread independently confirmed: “The message is generated by the LiteSpeed server component.” LiteSpeed’s documentation describes a server-level reCAPTCHA feature that system administrators can enable globally, with a “Trigger Sensitivity” scale and a bot whitelist that includes Google and Bing by default, but not AI crawlers. LiteSpeed’s own blog describes this as a “server-wide DDoS protection” feature, positioning it as infrastructure-level protection rather than a per-site configuration. On shared hosting, these server-level settings are controlled exclusively by the hosting provider’s engineers. Customers cannot access or modify them.

We were unable to confirm this specific mechanism on the affected server: the origin is hidden behind hcdn, SSH access was not available, and the server header only shows the CDN proxy. The LiteSpeed reCAPTCHA hypothesis is well-supported by community evidence and consistent with every observed behavior, but it remains unconfirmed for this specific infrastructure instance.

Sources: Cloudflare Community — “Bot verification page by Hostinger is being cached on Cloudflare CDN”, WordPress.org — “My website showing bot verification”, LiteSpeed Documentation — reCAPTCHA Protection, LiteSpeed Blog — reCAPTCHA Server-Wide Protection

Why AI Crawlers Are Uniquely Vulnerable

AI web crawlers operated by OpenAI (GPTBot, ChatGPT-User), Anthropic (ClaudeBot), Perplexity (PerplexityBot), and similar services share characteristics that make them disproportionately likely to trigger behavioral bot detection:

Known, published IP ranges. These services operate from well-known cloud infrastructure (Azure, GCP, AWS) and publish their IP ranges for transparency. Ironically, this transparency makes them easy targets. Any system filtering by IP range can block them with precision, and our testing confirmed this is exactly what’s happening, since the same user-agent strings from unpublished VPS IPs pass without challenge.

Headless request patterns. AI crawlers typically make HTTP requests without full browser execution environments. They don’t run JavaScript (or run it minimally), don’t load images, and don’t exhibit the behavioral patterns of a human with a mouse and keyboard. This is exactly what challenge pages are designed to catch.

Request frequency. AI services may make many requests in rapid succession as they index or retrieve content. Rate-based detection will flag this as potentially abusive, even when the crawling rate is well within published guidelines.

The result is a near-perfect false positive scenario: legitimate, authorized crawlers that the site owner wants to access their content are exactly the traffic that aggressive edge protection is most likely to block.

The Illusion of Control

What makes this situation particularly maddening is not just that the blocking happens; it’s that Hostinger’s own dashboard actively reassures the customer that everything is fine.

The AI Audit feature within the CDN settings explicitly lets customers manage AI bot access. Site owners can review a list of known AI crawlers and set each one to “Allow” or “Block.” In the case that prompted this investigation, every AI bot was set to Allow. The dashboard reported 116 total requests, 116 allowed, zero blocked. It even broke down the traffic by crawler: 64 requests from ClaudeBot (Anthropic), 33 from ChatGPT-User (OpenAI), 9 from OAI-SearchBot (OpenAI), 7 from GPTBot (OpenAI), 2 from meta-externalagent (Meta), 1 from PerplexityBot (Perplexity). All “allowed.” Zero blocked.

And yet every one of those crawlers was receiving a “Verifying that you are not a robot…” challenge page instead of content.

Now that we know hcdn is in the request path when the CDN is active (positioned between visitors and the origin server) the dashboard numbers make sense. The most likely explanation is that the CDN’s AI Audit feature is checking its own policy: “Is this bot on my block list? No. Request allowed.” It then forwards the request to the origin infrastructure behind it. Something in that origin infrastructure (most likely LiteSpeed’s server-level reCAPTCHA, based on community reports) inspects the request independently, determines it comes from a known AI service IP range, and serves a challenge page. The CDN accurately logged its own decision. It likely has no visibility into what happened after it passed the request along.

The CDN Security Level (the other customer-facing security feature) was set to “Essentially Off.” So neither of the two security controls the customer can see and configure is responsible for the blocking.

This means the dashboard is worse than useless. It’s actively misleading. A site owner investigating AI crawler access will check this panel, see 116 allowed requests and zero blocks, and reasonably conclude that AI bots are reaching their content. The dashboard becomes a diagnostic dead end, and in our investigation, it was exactly that. It cost time and directed attention away from the actual cause.

The disconnect between what the CDN reports and what visitors actually receive is the clearest evidence that Hostinger’s infrastructure contains independent systems making access decisions about incoming traffic, and that the ones the customer can see and configure are not the ones doing the blocking.

What “Invisible to AI” Actually Means — And Doesn’t

The full picture of what this blocking means (and doesn’t mean) is more nuanced than “invisible to AI.” But the nuance doesn’t make it less damaging, and being precise about it matters for understanding who gets hurt and how.

“AI can’t access your site” is a useful shorthand, but it obscures a more complex reality. AI tools don’t get their information about a website from a single source; they use at least three distinct paths, and Hostinger’s edge protection doesn’t block all of them equally.

Path 1: Training Data (Pre-Baked Knowledge)

AI models like GPT and Claude are trained on massive datasets crawled from the web. Whatever these crawlers ingested before the blocking started—or whatever they picked up indirectly from third-party sources like directories, social media profiles, and industry listings—gets baked into the model’s weights. This is how an AI might “know” about a business even if it can’t currently access the website. Training knowledge is a snapshot; it doesn’t update in real time, but it persists.

Path 2: Web Search (Real-Time, Indirect)

When you ask Claude or ChatGPT a question and it searches the web, it’s typically querying a search engine index (Google or Bing) not crawling the site directly. The chain looks like this:

User asks a question

↓

AI queries a search engine

↓

Search engine returns results from its index

↓

AI reads snippets and results

↓

AI formulates an answer

In this path, the AI never touches the site directly. It relies on Googlebot and Bingbot having already crawled and indexed the content. If Google can crawl the site (and in the case that prompted this investigation, Google’s Rich Results Test confirmed it could), the site can still appear in AI answers through this indirect path.

Path 3: Live Browsing / Direct Fetch (Real-Time, Direct)

This is ChatGPT’s “Browse” mode, Claude’s web fetch capability, and Perplexity’s real-time citation engine. The AI tool directly requests the page to read its current content. This is the path Hostinger’s edge protection blocks. When a user says “go read this website and tell me about it,” or when Perplexity fetches a source to quote and cite, the request originates from the AI service’s datacenter infrastructure and hits the verification wall.

What’s Actually Blocked — And What We Can Prove

Being precise about what we know versus what we’re inferring matters:

Provably blocked: Direct real-time fetching from AI service IP ranges. This was confirmed through diagnostic testing—Claude’s web fetch, and by extension any AI tool making direct HTTP requests from its published infrastructure IPs, receives the challenge page instead of content.

Likely affected, but inferred: Future training crawls. GPTBot and ClaudeBot are crawlers operated by OpenAI and Anthropic that, per their public documentation, may be used to improve AI models. It’s reasonable to assume that if these crawlers are hitting the same challenge page, new content won’t make it into future training datasets. But the internal architectures of these training pipelines aren’t public, and training crawls could conceivably originate from different infrastructure than the real-time services we tested.

Likely unaffected: Search-grounded AI answers. If Google and Bing can still crawl and index the site, AI tools that answer questions by searching these engines can still surface the site’s content indirectly. The blocking affects the AI service’s own crawlers, not Google’s or Bing’s (though as the community reports document, Hostinger’s edge protection has intermittently blocked Googlebot too, making even this path unreliable).

The Compounding Problem for Newer Sites

This distinction matters especially for newer or lower-authority websites. A well-established site with years of backlinks, directory listings, and social media mentions has a safety net: even if direct AI crawling is blocked, there’s enough third-party signal in training data and search indexes for AI tools to know the site exists. A newer site doesn’t have that cushion.

For a site that launched recently and is still building domain authority, the three paths compound against each other. Training data contains little or nothing about the site because it hasn’t been around long enough. Traditional search rankings are still developing, so the site may not appear in the results AI tools query via search. And direct crawling (the one path where fresh, authoritative content could make an immediate impression) is blocked by the hosting provider’s edge layer.

The result is that Hostinger’s bot protection disproportionately harms exactly the sites that can least afford it: newer businesses trying to establish their presence in an increasingly AI-mediated internet. For established sites, the blocking is an inconvenience that degrades one of three discovery paths. For newer sites, it can close the last remaining door.

This also means that fixing the Hostinger blocking, while necessary, may not be sufficient on its own. A site that isn’t ranking in traditional search for its target terms won’t suddenly appear in AI answers just because direct crawling is unblocked. The full path to AI visibility requires both technical accessibility and the kind of search presence (domain authority, backlinks, structured data, directory listings) that gives AI tools a reason to surface the site in the first place. The hosting fix removes a barrier; the SEO and AEO work builds the signal.

The Business Impact: Larger Than It Appears

With that framework in mind, the business impact becomes clearer—and, for certain categories of sites, more severe than a simple “blocked = invisible” framing would suggest.

The immediate impact, a website being inaccessible to AI answer engines, might sound like a niche technical concern, but it’s not. The landscape of how people find information online is undergoing its most significant shift since Google displaced Yahoo.

The Rise of AI-Powered Discovery

AI assistants are rapidly becoming primary discovery channels. When a user asks ChatGPT “What agencies in my area specialize in AI-powered marketing?” or asks Perplexity “Who can help with digital marketing strategy?”, the answer is synthesized from some combination of training knowledge, search results, and live-crawled content. A site that is blocked from direct crawling, absent from training data, and still building search authority is invisible across all three paths simultaneously.

SEO Damage Is Already Documented

The impact extends well beyond AI answer engines. As the WebHostingTalk and Reddit reports demonstrate, Hostinger’s edge protection has also challenged and blocked Googlebot, resulting in pages dropping from first-page rankings to being completely deindexed, “Page with redirect” errors flooding Google Search Console, hundreds of affected pages per site, and traffic loss with no corresponding change on the site owner’s end.

When your hosting provider’s security layer can intermittently block the world’s dominant search engine without your knowledge or consent, the business risk is existential for any organization that depends on organic discoverability.

The Hidden Scale

The true number of affected sites is unknowable from the outside, because the defining characteristic of this problem is that site owners don’t know it’s happening. Your site loads fine when you visit it. Your uptime monitoring tools, running from standard monitoring IPs, report everything is normal. Google Search Console might show errors, but those often get attributed to other causes. The challenge page only appears to specific traffic from specific IP ranges—precisely the traffic you’d never think to test for.

The reports cataloged in this investigation come from technically sophisticated users who had the skills and persistence to diagnose an invisible problem. How many small business owners are simply wondering why their site isn’t showing up in AI answers, never suspecting their hosting provider is the cause? How many are blaming their SEO consultant, their web developer, their content strategy…anything but the hosting they’re paying for every month?

Hostinger hosts millions of websites. Even if only a fraction of their Cloud Startup and shared hosting customers are affected, the aggregate impact on the web’s accessibility to AI services could be substantial.

Remediation Options for Affected Site Owners

The options are limited. Some are more proven than others.

Option 1: Cloudflare Proxy as Interception Layer (Uncertain, Moderate Effort)

Placing Cloudflare in front of the site (proxying DNS through Cloudflare) may allow Cloudflare to serve cached content to AI crawlers before the request reaches Hostinger’s edge. However, this approach carries known risks: if Hostinger’s edge protection inspects the actual connecting IP (which would be Cloudflare’s IP range, itself a datacenter range) or forwarded headers, it may still trigger the challenge. Worse, as documented in the Cloudflare community forums, the challenge page can be cached by Cloudflare and served to all visitors, turning an intermittent problem into a total outage. This approach requires careful testing and comes with no guarantees.

Option 2: Hostinger VPS Upgrade (Unconfirmed)

Hostinger support suggests that VPS plans provide more granular control over edge protection settings. However, at the time of this report, it remains untested whether Hostinger’s edge-level bot protection behaves differently on VPS plans versus Cloud Startup plans. The protection layer is upstream of the hosting environment itself, so there is no guarantee that a VPS on the same Hostinger infrastructure won’t exhibit the same behavior. Before committing to a VPS upgrade as a fix, affected users should ideally test by provisioning a Hostinger VPS, deploying a test page, and verifying that AI crawlers can access it without challenge. Upgrading on the assumption that VPS resolves the issue (without testing )risks paying more for the same problem.

Option 3: Migration to a Different Host (Most Reliable, Highest Effort)

Migrating to a hosting provider that does not impose unconfigurable bot protection is the most reliable long-term solution. However, it’s worth noting that Hostinger is unlikely to be the only shared hosting provider deploying aggressive edge-level bot challenges—any provider running similar infrastructure could exhibit the same behavior.

The safest long-term approach is a VPS or cloud server where you control the full stack, including what gets challenged and what doesn’t. Suitable options include cloud VPS providers (DigitalOcean, Linode/Akamai, Vultr), cloud platforms (AWS Lightsail, Google Cloud), or managed WordPress hosts (Kinsta, WP Engine, Flywheel, Cloudways)…though managed hosts still make infrastructure decisions on your behalf, so the same validation applies.

The recommended approach is to first clone the site to a test environment on the target host, verify that AI crawlers can access it without challenge, and then execute a full migration with DNS cutover. The key validation step is the same regardless of destination: confirm that requests from AI service IP ranges return actual page content, not a challenge page.

The Bigger Picture: What This Means for the Web

Bot protection is a legitimate and necessary security function. Nobody disputes that. Hosting providers face real threats from credential stuffing, scraping, DDoS attacks, and automated abuse. Protecting customers from those threats is part of the service.

But deploying aggressive, unconfigurable bot challenges that can block search engines and AI crawlers—without customer notification, without opt-out, and without visibility into what’s happening—is obviously far from ideal.

The AI crawler ecosystem is young and still establishing norms. Google spent two decades building relationships with hosting providers, implementing verification mechanisms (like reverse DNS for Googlebot), and creating a web where search engine access is a given. AI services are at the beginning of that process. They publish their IP ranges. They respect robots.txt. They’re building the equivalent of Googlebot verification.

But none of that matters if the hosting provider’s edge layer challenges them before the request ever reaches the server where robots.txt lives.

For AI service operators: The challenge of accessing content behind aggressive bot protection is not limited to Hostinger. As more hosting providers deploy edge-level bot management, AI crawlers will need to establish trusted-crawler programs similar to Googlebot’s verification system. Publishing IP ranges is a necessary start, but not sufficient when hosting infrastructure blocks at the IP level before any application-layer negotiation occurs.

For site owners: Test your AI visibility. Today. Ask ChatGPT to summarize your homepage (by browsing it). Ask Claude to find information on your site (again, by browsing it). Ask Perplexity what they know about your business. If the answer is “I can’t access that site” or “I see a verification page,” you have a problem, and it might not be yours to fix from within your hosting control panel.

For the hosting industry: The web is changing. AI-powered discovery is not a fad; it is the next evolution of how the internet is navigated. Hosting providers that make their customers invisible to this evolution are going to find themselves on the wrong side of customer trust. And in hosting, once trust is lost, migration is one rsync away.

A Note on Methodology

Hostinger was not contacted for official comment prior to publication. This report is based on direct technical diagnostic testing of the affected site, statements from Hostinger’s AI support system (Kodee), and corroborating reports from independent community sources. We welcome a response from Hostinger and will update this report with any official statement provided.

Conclusion

The case that prompted this investigation is not unique. It is one visible instance of a systemic issue in which Hostinger’s infrastructure-level bot protection (deployed without customer notification, absent from customer-facing controls, and resistant to customer-initiated resolution) is silently blocking AI crawlers from accessing websites on Cloud Startup and similar hosting plans.

The affected site owners have done nothing wrong. They’ve configured their sites correctly, welcomed AI crawlers explicitly, and checked every setting available to them. The block exists at a layer they cannot see, in a system they cannot configure, enforced by a decision they were never consulted about.

In an era where AI-powered discovery is rapidly becoming as important as traditional search, an invisible wall between your website and the AI internet isn’t just a technical inconvenience…it’s a business threat hiding in plain sight, and the people behind that wall need to know it’s there.

Appendix: Source Index

The following sources were referenced in this investigation. They span community forums, social media, support threads, and technical Q&A sites, and collectively document a pattern of reports from July 2024 through February 2026.

WebHostingTalk — System engineers confirmed enabling protection unilaterally; Googlebot blocked; SEO damage. Thread #1944630
LowEndTalk — Forced verification on Hostinger blocking crawlers; infrastructure-level issue. Discussion #207843
Reddit r/Hostinger — ~150 pages affected; rankings lost; fix only on VPS; OP migrated to AWS. Thread
Reddit r/Hostinger — Users seeking to disable robot verification (mid-2024). Thread
Cloudflare Community — Hostinger bot verification cached by Cloudflare CDN, amplifying outage. Thread
StackOverflow — Bot verification hitting Laravel API apps on Hostinger (non-WordPress). Q #79647763
WordPress.org — WordPress site showing bot verification; LiteSpeed server component identified. Support Thread
X/Twitter — Cloud Startup user: normal users blocked; ranking losses reported. Post
WordPress.org — Recurring bot verification on Hostinger-hosted WordPress site. Support Thread
Cloudflare Community — Bot verification appearing on PDF download URLs on Hostinger-hosted site. Thread
Reddit r/CloudFlare — Bing indexing “Bot Verification” as site title. Thread
Freelancer.com — Paid project to fix Hostinger bot verification issue. Project
LiteSpeed Docs — Server-level reCAPTCHA protection: trigger sensitivity, bot whitelist, server-admin-only config. Documentation
LiteSpeed Blog — reCAPTCHA server-wide DDoS protection feature overview. Blog Post
Hostinger Help Center — CDN Security Levels: threat-score-based challenge system. Documentation
Hostinger Blog — AI Audit feature announcement and CDN bot management. Blog Post

This report was prepared by Stonegate Web Security as part of an active client investigation. Findings are based on direct technical diagnostic testing of the affected site, statements from Hostinger’s AI support system (Kodee), and corroborating reports from independent community sources spanning July 2024 through February 2026. No confidential client data is disclosed in this report.