{"slug": "website-security-statistics-october-2026-survey", "title": "Website Security Statistics: October 2026 Survey", "summary": "Sitecheckly's October 2026 survey of the Tranco top 10,000 domains, covering 4,934 analyzable home pages, found that 6.2% of sites with readable robots.txt files block an AI search crawler and 15% block a training crawler, while 16% publish llms.txt. The audit also recorded an average security score of 77.1 out of 100, with Cross-Origin-Opener-Policy the most commonly missing header at 95% of pages, and detected at least one end-of-life or known-vulnerable component on 13% of home pages — a figure the project describes as a lower bound because detection depends on exposed version strings.", "body_md": "*Originally published on [Sitecheckly](https://sitecheckly.com/blog/website-security-statistics-october-2026).*\n\nThe survey found that 6.2% of sites with readable robots.txt files block an AI search crawler, while 15% block a training crawler. Across analyzed home pages, 16% publish llms.txt, and 13% run a detectable end-of-life or vulnerable component. That software figure is a lower bound because detection depends on exposed versions. These findings come from the [Sitecheckly open dataset](https://sitecheckly.com/data).\n\nThe October 2026 Sitecheckly survey used the Tranco top 10,000, list 7462X, covering 2026-10-02 to 2026-10-31. Home pages were fetched on 2026-11-01; 4,934 of 10,000 requested domains could be analyzed. The ranking came from [Tranco](https://tranco-list.eu). These are home-page benchmarks, not whole-site assessments.\n\nUse the website security statistics below to identify checks worth running on your own pages. A common finding is not automatically your most urgent problem. Confirm what applies to your application before changing it.\n\nThe average security score was **77.1 out of 100**. The most common missing header was Cross-Origin-Opener-Policy, but the appropriate response depends on what the page does.\n\nThe following shares apply to the analyzed home pages:\n\n| Missing header | Share | Owner action | \n|---|---|---|\n| Cross-Origin-Opener-Policy | 95% | Assess cross-origin isolation needs before choosing a policy. | \n| Referrer-Policy | 73% | Choose a policy that limits unnecessary URL sharing. | \n| Content-Security-Policy | 66% | Build and test a policy for the resources the page needs. | \n| X-Content-Type-Options | 54% | Set the header to the `nosniff` value. | \n\nUse the [security headers guide](https://sitecheckly.com/blog/security-headers-list-recommended-values) for implementation details. A missing header is a configuration finding to assess, not proof of an exploitable vulnerability or a successful attack.\n\nTwo separate findings need their own review:\n\nDo not put script integrity work in the same task as response-header configuration. Give each change an owner and test it against the page's actual dependencies.\n\nTo check your own page, run the free, passive [security audit](https://sitecheckly.com/security-audit). It checks the URL entered, requires no sign-up, and does not audit every page on the site.\n\nThe survey detected at least one end-of-life or known-vulnerable component on **13%** of analyzed home pages. Only common components with exposed versions could be checked, so this is a lower-bound detection figure, not a complete software inventory.\n\nEach row below uses its own exposed-version sample. End-of-life and known-vulnerability categories can overlap. **Do not add the shares.**\n\n| Technology | Exposed-version sample | End of life | Known vulnerability | Action | \n|---|---|---|---|---|\n| jQuery | 661 sites | 30% | 44% | Upgrade and test dependent scripts. | \n| WordPress | 201 sites | 0.0% | 3.5% | Update core and verify compatibility. | \n| Font Awesome | 147 sites | 45% | 0.0% | Move to a supported release. | \n| Nginx | 146 sites | 70% | 57% | Check vendor support and patch status. | \n| Drupal | 135 sites | 7.4% | 0.0% | Update core and modules. | \n| PHP | 110 sites | 42% | 42% | Upgrade the runtime and test the application. | \n| Bootstrap | 95 sites | 52% | 41% | Upgrade and test layouts and scripts. | \n\nAn advisory match needs verification. A Linux distribution may backport a security fix without changing the exposed version string, which can make version-based risk estimates too high. Conversely, a component that exposes no version may escape these checks. The [methodology](https://sitecheckly.com/methodology) explains these detection limits.\n\nFor your own maintenance queue, record the detected version, the installed package's patch status, and the team responsible for the upgrade. Do not treat a hidden version as evidence that software is current.\n\nThe average AI-search readiness score was **66.4 out of 100**. The survey found gaps in structured data and in how pages presented answers.\n\n| Finding | Share | \n|---|---|\n| No Organization schema | 72% | \n| No concise answer-first paragraphs detected | 70% | \n| No question-style subheadings | 68% | \n| No Schema.org structured data found | 51% | \n\nTreat these as review prompts, not a template every page must follow. Use accurate, relevant structured data. Put a direct answer near the start when the page addresses a question. Use question-style headings when they make the content easier to navigate, not simply to satisfy a check.\n\nThe free [AEO audit](https://sitecheckly.com/aeo-audit) checks the URL entered and can help identify these findings. Passing the checks does not guarantee an AI-search citation.\n\n**llms.txt adoption was 16%.** That is an adoption measure, not a requirement for visibility. The file remains a proposal, and major engines have not committed to reading it. Google's [guidance for AI features in Search](https://developers.google.com/search/docs/appearance/ai-features) says no new AI text files are needed to appear in those features. Keep that distinction in mind when reviewing [AI crawler access and related files](https://sitecheckly.com/blog/ai-crawlers-list-user-agents): publishing an optional file should not displace work on intended crawler access or useful page content.\n\nAmong the **4,546 sites with readable robots.txt**, **6.2%** blocked at least one AI search crawler, compared with **15%** blocking at least one training crawler. In that same group, **9.2%** blocked training crawlers while allowing AI search crawlers.\n\nThese AI crawler blocking statistics show why a blanket “AI bots allowed or blocked” label is not precise enough. Search access and training permissions need separate decisions.\n\nReported blocking shares for selected agents were:\n\n| User agent | Share blocking it | \n|---|---|\n| CCBot | 12% | \n| Bytespider | 11% | \n| GPTBot | 11% | \n| ClaudeBot | 10% | \n| Google-Extended | 9.3% | \n\nAll shares in this table use the readable-robots.txt group, not every analyzed home page.\n\nCheck the purpose of each agent before changing policy:\n\nBlocking a search crawler can affect that engine's ability to fetch content. Allowing it does not promise inclusion or citations.\n\nWrite down your intended policy, then test representative URLs against the actual robots.txt rules. Under [RFC 9309](https://datatracker.ietf.org/doc/html/rfc9309), the longest matching rule wins. Do not assume that the first rule in the file decides the result.\n\nThe website SEO statistics point to several practical page-level checks:\n\n| Finding | Share | Owner action | \n|---|---|---|\n| Images missing alt text | 61% | Write useful alternatives where needed. | \n| Title length outside the recommended range | 49% | Review titles for clarity rather than length alone. | \n| No h1 found | 34% | Add a descriptive main heading where appropriate. | \n| No canonical URL | 31% | Review canonicalization and the intended preferred URL. | \n\nRun the free [SEO audit](https://sitecheckly.com/seo-audit) on the URL you want to review. Use the results to investigate the page, not to make automatic edits without context.\n\nThe survey also detected these CMS shares:\n\n| CMS | Share of analyzed home pages | \n|---|---|\n| WordPress | 12% | \n| Drupal | 3.6% | \n| Adobe Experience Manager | 2.4% | \n\nThese are detection shares, not a complete CMS census. Maintain your own platform inventory and name a maintenance owner for each system. That inventory should be more authoritative than what an external home-page check can identify.\n\nThere is also a separate front-end dependency finding: **31% of 680 sites exposing a jQuery version ran jQuery 1.x or 2.x**. This is a different version-exposing group from the software-health table above.\n\nUse that finding as a prompt to inventory front-end dependencies, plan upgrades, and test compatibility. Keep the two jQuery samples separate when comparing results or reporting progress.\n\nThe survey analyzed home-page responses fetched over HTTP or HTTPS, without rendering JavaScript. It also included checks beyond those responses, such as DNS CAA records. It respected robots.txt. Domains that could not be analyzed were mostly CDN, DNS and API hosts, sites asking crawlers to stay away, or sites blocking automated requests.\n\nThe scope and fetch dates are stated near the top of this report. The [methodology](https://sitecheckly.com/methodology) describes the collection approach and its limits.\n\nRead the benchmarks with these constraints in mind:\n\nThe reported figures and denominators are available in the [open dataset, licensed under CC BY 4.0](https://sitecheckly.com/data).\n\n**What to do next**\n\n**Does a missing security header mean a site is compromised?**\n\nNo. A missing header is a configuration finding, not evidence that an attack has succeeded. Its importance depends on the application and the protection the header would provide.\n\n**Can a site block training crawlers without blocking AI search crawlers?**\n\nYes. Operators can write separate robots.txt rules for different user agents, then check that the rules reflect their intended policy.\n\n**Does an exposed vulnerable version prove the installation is unpatched?**\n\nNo. A distribution may backport a security fix without changing the version string used for detection. Check the vendor's patch information before assessing the risk.\n\n**Can Sitecheckly audit every page in a site at once?**\n\nNo. Each run audits the single URL entered. The security audit is separate from the SEO and AEO audits.\n\nWant to see how your own site does? Run a free audit at [sitecheckly.com](https://sitecheckly.com/?utm_source=devto).\n\n*Figures in this article come from Sitecheckly's own audit data; see the [methodology](https://sitecheckly.com/methodology).*", "url": "https://wpnews.pro/news/website-security-statistics-october-2026-survey", "canonical_source": "https://dev.to/hieu_le_f3630aa13143b35d8/website-security-statistics-october-2026-survey-40cl", "published_at": "2026-11-05 08:13:50+00:00", "updated_at": "2026-11-05 08:19:31.020407+00:00", "lang": "en", "topics": ["ai-crawlers", "agent-protocols"], "entities": ["Sitecheckly", "Tranco", "WordPress", "jQuery", "Nginx", "PHP", "Drupal", "Bootstrap"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/website-security-statistics-october-2026-survey", "markdown": "https://wpnews.pro/news/website-security-statistics-october-2026-survey.md", "text": "https://wpnews.pro/news/website-security-statistics-october-2026-survey.txt", "jsonld": "https://wpnews.pro/news/website-security-statistics-october-2026-survey.jsonld"}}