Security Headers for Small Business Websites: A Practical Before-and-After Guide

Security headers are browser guardrails, not an SEO shortcut

HTTP security headers are instructions sent with a web response. They can tell a browser to use HTTPS for future visits, refuse unexpected content types, limit who may frame a page, control how much referrer information is shared, or restrict where scripts and other resources may load from.

That makes them useful security controls, but not a substitute for secure software, updates, backups, access control or vulnerability management. It is also important not to turn a security scan into an SEO score. Google recommends HTTPS and good page experience, but its public guidance does not identify headers such as Content-Security-Policy, X-Frame-Options or Referrer-Policy as direct ranking signals. Google also cautions site owners to verify third-party SEO-tool recommendations against official guidance rather than treating a tool score as Google data. See also Google's page-experience guidance.

If a scan flags missing headers, treat the result as a technical finding to investigate. The goal is to reduce an appropriate risk without breaking the website. For a deeper explanation of individual findings, see ScanMySEO's missing security headers guide.

Which security headers matter most on a small-business site?

There is no single header bundle that every website should copy. A brochure site, a WooCommerce store, a membership site and a site that embeds booking or payment tools have different dependencies. The table below is a practical starting point rather than a universal pass/fail standard.

MDN documents the current behaviour of HSTS, X-Content-Type-Options and Referrer-Policy. For a broader technical reference, the OWASP HTTP Headers Cheat Sheet explains both recommended and obsolete headers.

What security headers change for users and search

The most direct benefit is browser behaviour. A correct HSTS policy reduces downgrade risk after the browser has learned the policy. A CSP can limit where executable resources come from. Framing controls can reduce clickjacking exposure. Referrer Policy can reduce accidental URL-data leakage. These are security and privacy outcomes first.

HTTPS itself is a separate prerequisite. Google recommends using HTTPS, and browsers may warn users about insecure HTTP pages. If your website still serves important pages over HTTP, fix that before treating security-header tuning as the main job. ScanMySEO's guide to URLs that are not using HTTPS covers that foundation.

Do not assume that adding more headers automatically makes a site secure. MDN's HTTP Observatory explicitly notes that even a top grade cannot test for problems such as outdated software, vulnerable content-management-system plugins, SQL injection or weak password handling. The scan is evidence about a defined set of browser-facing controls, not a complete security assessment. See the HTTP Observatory FAQ.

Diagnose the current state before changing anything

A useful before-and-after comparison starts with a record of what the server sends today and what the website depends on. This prevents a common failure mode: adding a strict policy, discovering that a checkout or form is broken, then weakening the policy until the scanner turns green.

1. Confirm HTTPS first. Load the homepage, important landing pages, login/admin areas and any checkout or form flow over HTTPS. Check that HTTP requests redirect to HTTPS and that certificates are valid. If you use subdomains, list them before considering HSTS includeSubDomains.
2. Inspect the final response headers. In a browser, open Developer Tools, use the Network panel, reload the page and inspect the document response. You can also run curl -I https://example.com/. Check the final HTTPS response, not only an intermediate redirect.
3. Inventory third-party dependencies. Record analytics, tag managers, ad networks, cookie-consent tools, payment providers, live chat, booking systems, maps, YouTube/Vimeo embeds, reCAPTCHA, externally hosted fonts and CDNs. CSP decisions depend on this list.
4. Record the baseline. Save the headers, any automated scan result, and a short list of business-critical journeys that currently work. This is your rollback and verification reference.
5. Use automated tests as a prompt, not a verdict. Tools such as MDN HTTP Observatory can quickly highlight missing controls, but the right configuration still depends on the site.

Before and after: a realistic small-business example

Consider a hypothetical local-services WordPress site. It already uses HTTPS, has a contact form, Google Analytics, a cookie-consent tool and a YouTube testimonial embed. The owner runs a header check and sees a sparse response:

HTTP/2 200
content-type: text/html; charset=UTF-8
server: nginx

# No HSTS
# No CSP or frame-ancestors policy
# No X-Content-Type-Options
# No explicit Referrer-Policy

The correct response is not “paste the strictest header pack available.” The site first needs to understand which external resources are required and which systems control the response headers: the host, CDN, reverse proxy, web server or WordPress itself.

Step 1: add lower-risk controls and decide framing

The site can usually test X-Content-Type-Options: nosniff and an explicit referrer policy with relatively little disruption, provided resource content types are already correct. It should also decide whether other sites are allowed to frame its pages. If framing is not required, a CSP frame-ancestors policy can express that decision; X-Frame-Options can provide an older compatibility layer. MDN notes that CSP frame-ancestors provides more flexible framing control than X-Frame-Options.

Step 2: design CSP from the site's real dependencies

CSP is where “one-size-fits-all” examples cause the most trouble. WordPress themes and plugins may load scripts or styles inline, and marketing tools may use several domains. Start with an intended policy in Content-Security-Policy-Report-Only, review violations, fix or allow legitimate dependencies, then enforce the policy once the important journeys are clean. MDN specifically recommends testing CSP in report-only mode before enforcement. See its practical CSP implementation guide.

A limited starter policy might first protect specific areas such as framing and plugin content while the team works toward stronger script restrictions:

Content-Security-Policy: object-src 'none'; base-uri 'self'; frame-ancestors 'self'

This is intentionally not presented as a complete XSS defence. A mature CSP normally needs site-specific source restrictions and, for stronger script protection, may require nonces or hashes generated by the application. Avoid adding broad wildcards or 'unsafe-inline' everywhere merely to silence violations; that can remove much of the protection you were trying to add.

Step 3: add HSTS only after HTTPS is proven

HSTS should not be the first change on a site that has not audited its HTTPS coverage. Browsers remember the HSTS policy for its max-age, and includeSubDomains extends that behaviour to subdomains. MDN also notes that browsers ignore an HSTS header received over insecure HTTP, so the header belongs on the HTTPS response.

For an initial rollout, a cautious team may use a short max-age while checking for missed hostnames or certificate problems, then increase it after confidence grows. The OWASP HSTS Cheat Sheet gives a one-day example specifically for an initial rollout and warns that preload can have long-lived consequences. Do not add preload because a scanner awards points for it.

A defensible “after” state

After testing, the final header set for this hypothetical site might include the following. The exact CSP and HSTS scope still depend on the site's own resources and subdomains:

Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: object-src 'none'; base-uri 'self'; frame-ancestors 'self'
X-Frame-Options: SAMEORIGIN

That example deliberately avoids includeSubDomains, preload and a broad script allowlist because we have not proved they are safe for this hypothetical business. A more restrictive CSP can be added after report-only testing shows exactly which scripts, styles, frames, images and connections are required.

A safer WordPress and small-business implementation workflow

1. Take a restorable backup and know how to roll back. Header changes can affect every page. If your host or CDN has versioned configuration, use it.
2. Choose the right configuration layer. Prefer the host, CDN, reverse proxy or web-server configuration when that is the layer consistently serving the responses. A WordPress plugin may be appropriate on some sites, but it may not control cached, static or edge-served responses.
3. Fix HTTPS and certificate problems before HSTS. Verify HTTP-to-HTTPS redirects, certificate coverage, renewal and important subdomains first.
4. Add simpler controls and retest. X-Content-Type-Options, an appropriate Referrer-Policy, and framing controls are often easier to validate than a full CSP.
5. Roll out CSP in report-only mode. Test the homepage, forms, login, search, checkout, account area, consent banner, analytics, embeds and any campaign landing pages. Review violations rather than blindly allowing every blocked domain.
6. Enforce CSP once expected behaviour is understood. Re-test after every material plugin, theme, tag-manager or payment integration change because dependencies can change.
7. Roll HSTS forward deliberately. Increase max-age after the HTTPS setup is stable. Add includeSubDomains only when all affected subdomains can remain HTTPS. Treat preload as a separate, deliberate decision.
8. Consider Permissions Policy only for features you understand. It can be useful for explicitly disabling camera, microphone or geolocation where the site never needs them, but browser support and embedded-tool requirements vary.

Where should a WordPress owner configure the headers?

There is no single WordPress answer. On managed hosting, the safest route may be a hosting control panel or support request. On Cloudflare or another CDN, response-header rules may live at the edge. On Apache or Nginx, a developer or host may configure them at the server. A plugin can be convenient, but it adds another dependency and may not affect every response path.

If you do not control the server configuration, give your host a precise request rather than asking them to “add all security headers.” Tell them which hostname and pages are affected, whether framing is required, which subdomains exist, and which CSP stage you are in. That gives the person making the change enough context to avoid a blanket configuration that breaks the site.

Do not add obsolete headers because an old checklist says so

Security-header advice decays. A legacy checklist can recommend headers that current OWASP header guidance now discourages:

• X-XSS-Protection: OWASP recommends not setting it or explicitly disabling it with X-XSS-Protection: 0, because the old browser XSS filters are obsolete and could create problems. Use CSP for modern browser-side XSS mitigation instead.
• Expect-CT: OWASP recommends removing it. Modern browser certificate-transparency handling made the old opt-in header unnecessary.
• Public-Key-Pins (HPKP): do not use it. Modern browsers no longer support it, and operational mistakes could make a site unreachable.

This is one reason a “100% header score” should never be the target. The target is an appropriate, supportable configuration based on current browser behaviour and your site's real risks.

Verify behaviour, not just header presence

A header is only successful if the browser receives it on the relevant responses and the website still works. After each rollout, check both technical presence and user journeys.

• Confirm the final HTTPS response contains the intended headers.
• Test the homepage, key service pages and high-traffic landing pages.
• Submit every important form and confirm success/error states.
• Test WordPress login and admin workflows if your configuration affects them.
• Test checkout, account and payment flows where relevant.
• Play embedded videos, maps, booking widgets and live chat.
• Confirm analytics, tag-manager and consent tooling still fire as intended and lawfully configured.
• Check the browser console for CSP violations and blocked resources.
• Re-run your automated header test, but investigate differences instead of chasing the grade.
• Check representative mobile and desktop browsers, especially if you introduced Permissions Policy or advanced CSP features.

If a fix breaks the site, roll back or move back to report-only mode and identify the missing dependency. Do not permanently weaken the policy with a wildcard simply because it restores the page quickly.

Practical website hygiene goes beyond headers

Headers are one layer. For a WordPress site, routine maintenance can matter more than adding another response directive. WordPress's own hardening guidance recommends keeping plugins updated, deleting unused plugins, using strong passwords and two-step authentication, and maintaining regular backups. See the WordPress hardening handbook.

What should a small business fix first?

If time and budget are limited, use this order to reduce risk without turning the job into a security-header project for its own sake:

1. Make HTTPS reliable everywhere that matters. Fix certificate, redirect and mixed-HTTP problems first.
2. Keep the CMS and dependencies maintained. An unpatched plugin is not rescued by a perfect header score.
3. Add low-friction response protections. Verify Content-Type, add nosniff, choose an appropriate referrer policy and define framing behaviour.
4. Develop CSP as a tested policy. Use report-only mode, inventory legitimate third parties, then enforce.
5. Add HSTS after HTTPS readiness is proven. Expand duration and subdomain scope carefully.
6. Recheck after meaningful site changes. New plugins, tags, CDNs, booking systems, payment providers or domain changes can alter what the policy needs to allow.

The key distinction is simple: a missing header is a clue, not a diagnosis. The best implementation is the one that addresses a real browser-side risk, matches the site's architecture, survives verification and can be maintained when the site changes.