How many popular .uk websites switch on basic browser security settings?

The secure-connection rule is common; camera and microphone limits are rare

The received wisdom holds up best for HTTPS enforcement. The header known as HSTS tells a browser to refuse any insecure version of the site, and roughly seven in ten of the popular .uk home pages send it. Further down the list, the picture thins out. Permissions-Policy, which lets a site switch off features it never uses, such as location, camera and microphone, appears on only about one in eight.

These figures come from the home page alone, read as the server first sends it before any scripts run. A site that applies stricter settings on its checkout or login pages will not show that here.

A content security policy is the header that does the most work after a break-in. If an attacker slips a rogue script onto a page, a well-set policy can stop the browser from running it. On most of these sites, that safety net is missing.

Across the wider .uk web, HSTS leads the eight security tools detected

The popular sites are a small slice of the web. A broader view comes from the HTTP Archive's October 2026 crawl of 345,112 .uk home pages, which looks for the fingerprints of security technologies rather than reading headers directly.

On that wider set, HSTS was found on just under half of home pages, the most common of the 8 security tools measured. Cloudflare Bot Management came second of the 8, at 23.45%. This crawl counts .uk addresses only, so UK businesses trading on .com or other domains are not in it. Because it works from home-page fingerprints, it can also miss tools used deeper inside a site.

The two sources use different methods, so their HSTS shares are best read as separate snapshots. They agree on one thing: HSTS is the setting UK sites most often have in place.

Bot blocking spread quickly on the same sites

The twist is that site owners are adding protection, just of a different kind. Because the same sites are compared in both years, the change cannot be explained by a different list of sites being crawled.

Bot blocking sits in front of a website and screens automated traffic before it arrives. Security headers do a different job: they instruct the visitor's own browser how to behave once the page loads. Using one does not cover the other, and these figures show many sites relying on the first while leaving the second unset.

What this means for UK businesses

The good news is that the most common protection, forcing the secure connection, is already in place on most popular .uk home pages. If yours is missing it, you are behind the crowd.

The gaps sit with the less familiar headers. A content security policy and a permissions policy are both free, and both limit the damage if something goes wrong on your site. They are also the ones most likely to be missing.

Bot protection and security headers are separate jobs. If you already pay for a service that filters traffic, still check what your pages tell visitors' browsers.

The padlock is still worth having. It is the first line on a short list, and on most sites the rest of that list is a few server settings away.

We ran the same check on our own site

After finishing this study, we put sayu.co.uk through the checklist above. Agencies miss things too, and ours was no exception.

• HSTS: present, but set to last only one day while a site rebuild settled in. We have raised it to a year.
• Content security policy: missing. Our pages use a few small inline scripts that a strict policy would block, so we had put it off. We now send it in report-only form, and browsers report each problem to a log on our own server. That shows us what a strict policy would break before we switch it on.
• Permissions policy: missing. We now switch off camera, microphone, location, payment and USB access, none of which the site uses.

The bigger finding was next to the main site

Checking the main site led us to the other web addresses on the same server: older tools, test sites and internal systems that had built up over the years. Several still answered over plain HTTP. Some were in daily use and simply lacked a redirect to the secure version. One redirected visitors to the insecure version. Others had not served anything useful for years.

We redirected every live address to HTTPS and switched off the ones nobody used. The second step matters as much as the first: a forgotten test site is easy to overlook, and it still carries your name.

It also explains why our HSTS rule does not yet cover subdomains. The includeSubDomains setting tells browsers to insist on HTTPS for every address under the domain. Adding it while any of them still relies on plain HTTP would make those addresses unreachable, so we will add it once every address has been confirmed.

How we built it

Header check (October 2026). We fetched the home page of every .uk website in the Chrome UX Report's top 500,000 (site list from the HTTP Archive crawl) once during the month, using a standard browser user agent. Only pages that answered with HTML were counted: 3,927 of 5,026. Security headers were read from the home page response, before any JavaScript ran. This is a direct count of what each server sent at one moment, so it is measured, and it is a single snapshot that says nothing about change over time. Settings on other pages of a site are not covered.

Security tools (HTTP Archive, October 2026 and October 2025). The share of .uk home pages where each of 8 security technologies was detected, out of 345,112 pages (349,106 a year earlier). Detection relies on home-page fingerprints and can miss tools used elsewhere on a site. The crawl's site list changes from month to month, so year-on-year moves in the full crawl partly reflect which sites were included. For that reason, the change in bot management quoted above uses only the 255,116 sites crawled in both years. Only .uk addresses are included.

The header check and the fingerprint crawl use different methods and site lists, so we have not set their HSTS shares against each other as a measured gap.