MonitorMojo Blog
Security Header Monitoring: What Security Headers Are and Why They Matter
Security headers are HTTP response headers that tell browsers how to behave when serving your website to visitors. They are not visible to users and do not change how the page looks, but they provide real protection against common browser-based attacks. They are also one of the most frequently dropped signals after a website migration, platform change, or hosting update — which makes checking them a useful part of any website health review.
What security headers do
Security headers are instructions from a web server to a browser, sent alongside the page content. They tell the browser things like: do not allow this page to be loaded inside an iframe on another site (which prevents clickjacking attacks), do not allow the browser to guess the content type (which prevents certain injection attacks), only allow resources to be loaded from specific trusted origins (Content Security Policy), and only allow this site to be accessed over HTTPS for the next year (HSTS).
These headers are part of a defense-in-depth approach to web security. They do not replace other security measures like input validation or authentication, but they reduce the attack surface available to someone trying to exploit browser behavior.
For most business websites, the most relevant headers to check are: Strict-Transport-Security (HSTS), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Content-Security-Policy. Each serves a specific purpose and is recommended by security best practice guides including OWASP.
Why security headers disappear after migrations
Security headers are typically configured at the server or CDN level — in nginx configuration files, Apache .htaccess rules, Cloudflare settings, or a load balancer configuration. When a website is migrated to a new server, hosting provider, or CDN, the content often moves correctly while the server configuration does not.
This means a site that had all its security headers configured correctly before a migration can arrive at the new host without any of them. The website looks identical to visitors, but the browser-level protections are no longer in place. Without a post-migration health check, this gap can persist for months.
For agencies managing WordPress sites, security headers are also commonly configured through plugins. When a plugin is deactivated, updated, or conflicts with another plugin, the header configuration can change without any obvious sign that something has been removed.
Key security headers to check
HSTS (Strict-Transport-Security) tells browsers to always use HTTPS for the domain, preventing downgrade attacks where a connection is forced to use HTTP instead of HTTPS. Without HSTS, a browser might follow an HTTP link to a site rather than automatically upgrading to HTTPS.
X-Frame-Options prevents the site from being embedded in an iframe on another domain. This stops clickjacking attacks, where a malicious page overlays your site with invisible elements to capture clicks intended for your buttons or forms.
X-Content-Type-Options: nosniff tells browsers not to guess the content type of a response. Without this header, browsers may interpret a text file as executable code under some conditions, creating an injection risk. Referrer-Policy controls how much information is shared with other sites when a visitor clicks a link away from your site — important for privacy and for preventing referral data from leaking to untrusted sources.
Security headers and website care plans
For agencies delivering website care plans, security header status is a concrete deliverable that clients can understand without technical background. The message is simple: these protections are in place on your website and we check them regularly.
Including security header status in monthly health reports shows clients that the care plan covers browser-level security, not just uptime and backups. It also gives agencies a clear trigger for action: if a header disappears after an update or migration, the care plan covers investigating and restoring it.
Security header monitoring is also useful for demonstrating compliance with basic security best practices to clients in regulated industries — healthcare, finance, legal — where security hygiene affects their obligations to customers and partners.
How to check security headers
Security headers are returned in the HTTP response from the server, which means they can be checked by any tool that makes a real HTTP request and reads the response headers. A browser developer tools panel will show you the headers for a specific page load. An external website health check tool can surface whether key headers are present as part of a broader site review.
MonitorMojo includes security header signals as part of its standard website health check. When you run a check on a domain, you can see whether key security headers are present — alongside reachability, SSL status, response time, and domain risk notes — giving you a complete health picture in one workflow.
If a check shows that security headers are missing or incomplete, the next step is to add them through the appropriate configuration layer for your hosting environment: server configuration files, CDN settings, or a WordPress security plugin if applicable.
Who this is for
- Agencies who include security configuration in website care plan services
- Developers doing post-migration health checks on newly moved sites
- Website owners who want to confirm basic browser security protections are in place
- Teams managing WordPress sites where plugin changes can affect security configuration
- Anyone responsible for websites in regulated industries where security hygiene is required
Frequently Asked Questions
Do security headers affect how the website looks?
No. Security headers are instructions sent to the browser in the HTTP response — they are invisible to visitors and do not change the page's appearance, content, or functionality. They only affect how the browser handles the page at a security and privacy level.
What is the most important security header to have?
HSTS (Strict-Transport-Security) is often considered the highest priority because it enforces HTTPS across all connections to the domain. X-Frame-Options and X-Content-Type-Options are also widely recommended as baseline protections. Content-Security-Policy provides the most comprehensive control but also requires the most configuration effort to implement correctly.
How do security headers relate to SSL certificates?
SSL certificates enable HTTPS — the encrypted connection between browser and server. Security headers are a separate layer: they instruct the browser on how to behave once that connection is established. HSTS in particular links the two — it tells browsers to always use the HTTPS connection that the SSL certificate enables.
Can I add security headers to a WordPress site?
Yes. Security headers can be added to WordPress sites through: a security plugin like Wordfence or iThemes Security, .htaccess rules on Apache-based hosting, nginx configuration on nginx-based hosting, or CDN settings if the site is behind Cloudflare or a similar CDN. Each method has its own process and trade-offs.
Why does my security header check show different results for different pages?
Security headers can be configured at different levels — the root domain, specific subfolders, or individual pages — and different headers may be set for different paths. A health check on the homepage may show a complete header set while a check on the checkout page shows missing headers. Checking the pages that matter most for visitor trust is more useful than checking only the homepage.