All articles · Web Security

We Scanned the World's 100 Most Popular Websites: What They Get Wrong

By PerfoMetrix Team·November 3, 2026·5 min read

The world’s most visited websites are run by some of the best-funded engineering teams there are. So we wondered: do they get the basics right? On 1 November 2026 we ran one PerfoMetrix scan of the home page of each site on our World Top 100 list and added up the results.

The short answer: the hard parts are done everywhere, and the easy parts are skipped surprisingly often. Every site uses modern encryption, but most leave out security headers that take a single line of configuration. This post shares the figures. It names no site: the point is the pattern, and what it means for a site of any size.

How we measured

• Sites: the World Top 100 for September 2026, built from the Chrome UX Report’s most visited origins and ordered by the Tranco research ranking. Adult, gambling and piracy sites are excluded, as on our list pages.
• Scan: our normal passive scan of each home page, the same one anyone can run for free: the page and its response headers, the TLS handshake, public DNS records, blocklists, and Google’s Lighthouse through PageSpeed Insights on a mobile profile. No logins, no attacks, no more than a handful of requests per site. The methodology page explains how scores work.
• One snapshot: results are for one home page on one day. Inner pages, other countries and other days can differ.

Finding 1: A fifth of the top sites turn away automated visitors

21 of the 100 sites answered our scanner with an error status instead of their home page, which usually means bot protection decided our request wasn’t a person. That is a legitimate choice for a site under constant scraping, and our scanner respects it: we don’t disguise ourselves as a browser. The figures below therefore cover the 79 sites that answered normally, so we measured their real pages rather than an error screen.

Finding 2: Encryption is solved

Every site that answered served its page over HTTPS with a current TLS version, and none had an invalid certificate. Eight in ten (61 of 76 with security data) also send HSTS, which tells browsers never to use plain HTTP again, and half of those are on the browsers’ HSTS preload list.

A few gaps remain even here: 8 of the 76 didn’t redirect our plain http:// request to HTTPS.

Finding 3: The one-line headers are the most skipped

The surprising part is how often the cheapest protections are missing:

Shares of the 76 sites with security data.

Each of these is a response header, usually one line in a web server or CDN configuration. Referrer-Policy alone stops a page from leaking the full address of the page a visitor came from to every third party it loads; 70% of the top sites don’t send it. A third of the sites enforce no Content Security Policy, the main defence against injected scripts. Our guide to security headers explains each one, and the Security Headers Generator writes the lines for you.

Cookies tell a similar story: 29% set at least one cookie without the Secure flag on the home page, and more than half have cookies that scripts can read (no HttpOnly), which is sometimes intended but often not.

Finding 4: Email authentication is better, but not universal

Email spoofing is where a big brand has the most to lose, and most sites have done the work:

• DMARC: 76% have a policy that passes our check; 12% have none at all.
• SPF: 80% pass.
• MTA-STS, which forces encryption for mail delivered to the domain, is rare: 5 of 65 domains that receive mail.

If 12% of the world’s biggest brands still let anyone send mail in their name without a DMARC policy, smaller domains are worth checking too. Our post on moving DMARC to reject walks through it.

Finding 5: The rarely seen extras

• security.txt, the standard file telling researchers how to report a vulnerability, is published by only 25%.
• DNSSEC, which signs DNS answers, is enabled for 9%.
• CAA records, which limit who may issue certificates for the domain, exist for 43%.
• Version numbers in headers (Server, X-Powered-By) still show on 24%.
• Known vulnerable JavaScript libraries turned up on 2 of 75 sites.

Finding 6: Fast for real users, slow in the lab

Performance is where the picture splits. In Lighthouse’s lab test on a simulated mid-range phone, only 13% of the sites scored 90 or more, and only 11% had a “good” Largest Contentful Paint.

Yet real users see something better. In Chrome’s field data for the same pages, 63% have a good LCP, 60% a good INP (responsiveness) and 78% a good CLS (layout stability). Likely reasons: many of their visitors use fast devices and networks, are served from nearby servers, and come back with warm caches. The lab test assumes none of that.

The lesson for everyone else: lab scores are a diagnostic, field data is the verdict. Our post on why Lighthouse and real users disagree explains the gap, and the Core Web Vitals section of every report shows both.

Page weight is not a priority either: only 22% of the home pages stayed under our page-weight threshold.

Finding 7: Basic SEO markup is surprisingly loose

• Exactly one H1: only half of the home pages.
• A meta description of a useful length: 51%.
• Open Graph tags for link previews: 62% complete.

Home pages of famous brands don’t depend on these signals the way a new site does, so treat this as evidence that search engines cope with imperfect markup, not as permission to skip it.

Finding 8: No signs of compromise from the blocklists

None of the sites, or the third-party scripts they load, was listed by Google Web Risk or blocked by Quad9’s threat filtering, and none loaded a script from a host known to have been compromised.

The scores

Across all 100 scans the median overall score was 80 (a B). By grade: 21 A, 31 B, 35 C, 10 D and 3 F. Security was the strongest section (median 90), performance the weakest (median 67). Sites that blocked our scanner score lower partly because we could test less of them.

What this means for your site

If the most visited websites still skip one-line protections, your site probably does too, and you can fix it in an afternoon:

1. Add the missing security headers: HSTS, a Content Security Policy, nosniff, Referrer-Policy, Permissions-Policy and clickjacking protection.
2. Set Secure, HttpOnly and SameSite on your cookies.
3. Publish SPF and DMARC records, then move DMARC towards reject.
4. Publish a security.txt and a CAA record.
5. Judge speed by real-user data, and use the lab to find what to fix.

Run a free scan to see where you stand, or check one thing at a time with the Security Headers Checker.

Tags:researchsecurity headersHTTPSCore Web Vitalstop websitesDMARC