The difficult part is not enabling a cache. It is deciding which response may be stored, who may store it, how long it remains fresh, and what must happen when it becomes stale. A bad policy can serve old files, leak personalized pages between users, or make deployments appear broken. A good policy reduces latency and server work while keeping content correct.

This guide explains browser caches, shared caches, Cache-Control, ETag, Last-Modified, 304 Not Modified, CDN behavior, and practical configurations for common website content.

The HTTP caching layers

A response may pass through several independent caches between the application and the visitor:

1. Application cache: WordPress page caching, a framework response cache, or generated static HTML.
2. Reverse-proxy cache: Nginx, Varnish, Apache mod_cache, or a hosting platform cache in front of the application.
3. CDN cache: geographically distributed edge servers such as Cloudflare.
4. Browser cache: private storage controlled by the visitor’s browser.

These layers do not necessarily use the same cache key or expiration time. A CDN might keep an asset for a day while instructing the browser to keep it for an hour. A browser cache belongs to one user, while a CDN or reverse proxy is a shared cache that may serve the same stored response to thousands of users.

That distinction is fundamental: a response that is safe in a private browser cache may be dangerous in a shared cache.

Freshness, staleness, and revalidation

A stored response is fresh while its defined lifetime has not expired. A cache can normally reuse a fresh response without contacting the origin. Once the lifetime expires, the response becomes stale. Stale does not always mean unusable; the cache may ask the origin whether its copy is still current.

That check is called revalidation. If the resource has not changed, the origin can return 304 Not Modified without sending the response body again. If it has changed, the origin returns a new 200 OK response and representation.

Freshness avoids a network round trip entirely. Revalidation still requires a request, but it can save bandwidth and avoid retransmitting a large body.

Cache-Control directives explained

Cache-Control is the primary header for explicit caching behavior. Multiple directives are separated by commas.

no-cache does not mean do not cache

This is the most common HTTP caching misunderstanding. no-cache allows a response to be stored. It means that the stored response must be validated with the origin before it is reused. When the cached copy is still current, the origin can answer with a small 304 response.

Cache-Control: no-cache

Use no-store when the response must not be stored in a browser, CDN, proxy, or other compliant cache:

Cache-Control: no-store

Examples include responses containing particularly sensitive personal or financial information. Do not combine every restrictive directive out of habit. A header such as private, no-cache, no-store, max-age=0 is mostly noise because no-store already prohibits storage.

public and private control shared caches

private means the response is intended for one user and must not be stored by shared caches. It may still be stored by that user’s browser. A personalized account page might use:

Cache-Control: private, no-cache

The browser may store the response but must revalidate it before reuse. The CDN must not store it.

public explicitly allows shared-cache storage. It is useful for public resources, particularly when normal HTTP rules would otherwise make a response non-cacheable. Do not add public to a page merely because it can be visited without logging in; verify that its content, cookies, location, currency, experiments, and permissions cannot vary unexpectedly between users.

max-age and s-maxage set different lifetimes

max-age defines freshness in seconds. The age is measured from when the response was generated, not simply from when a cache received it. Shared caches commonly expose the current age through an Age header.

s-maxage applies only to shared caches and overrides max-age there. This lets a CDN refresh content more frequently while browsers retain it longer, or vice versa:

Cache-Control: public, max-age=300, s-maxage=3600

In this example, a browser treats the response as fresh for five minutes, while a compliant shared cache may keep it fresh for one hour. CDN cache rules can override origin headers, so always verify the behavior of the deployed configuration rather than assuming the header is the final authority.

ETag and Last-Modified are cache validators

Freshness determines when a cached response can be reused without asking. Validators help a cache check a stale response efficiently.

An ETag is an identifier for a particular representation. When the cache has an ETag, it can send it in If-None-Match:

If-None-Match: "33a64df5"

If that identifier still matches, the origin returns 304 Not Modified. Otherwise it returns the new content with a new ETag.

Last-Modified contains the modification timestamp. A cache can send it back through If-Modified-Since. Timestamps are less precise than representation-specific ETags, but they remain useful to caches, crawlers, and content-management systems. Current HTTP guidance favors sending both when practical; If-None-Match takes precedence when both conditional request headers are present.

HTTP/1.1 200 OK
Cache-Control: no-cache
ETag: "33a64df5"
Last-Modified: Mon, 13 Jul 2026 08:00:00 GMT

What a 304 Not Modified response does

A 304 Not Modified response tells the client that its stored representation is still valid. It has no response body. The browser combines the 304 metadata with its cached body and presents the resource as though it had received the full response.

A 304 is useful, but it is not as fast as a fresh cache hit: the browser still contacted the server and waited for a response. For versioned static assets that cannot change at the same URL, a long freshness lifetime is usually better than repeated revalidation.

The best pattern for versioned static assets

Build systems often place a content hash or version in filenames:

<link rel="stylesheet" href="/assets/app.a91f4c2.css">
<script src="/assets/app.738bc11.js" defer></script>

When the file changes, the URL changes. The old URL can therefore receive a long cache lifetime safely:

Cache-Control: public, max-age=31536000, immutable

This strategy is called cache busting. The HTML document should not receive the same long immutable policy because it must be able to reference the new asset filenames after deployment.

A practical policy for HTML

For non-personalized HTML that should always reflect the latest deployment, use validators with:

Cache-Control: no-cache

This allows storage while requiring validation before reuse. If page generation is expensive and a small amount of staleness is acceptable, a public page can instead use a short s-maxage at the CDN while browsers revalidate more frequently:

Cache-Control: public, max-age=0, s-maxage=300, must-revalidate

That pattern is appropriate only for genuinely public HTML. Logged-in pages, carts, checkout flows, dashboards, previews, password-protected content, and responses affected by user-specific cookies must bypass shared caches or use a rigorously designed cache key.

Vary changes the cache key

The Vary response header tells caches which request headers influence the representation. For compressed responses, a common example is:

Vary: Accept-Encoding

A cache can then keep separate compressed and uncompressed variants. Other possibilities include Accept for content negotiation or Accept-Language for language variants.

Use Vary carefully. Each request-header value can create another cache variant, reducing the hit rate. Vary: Cookie is especially broad because cookies often differ for nearly every visitor. For user-dependent pages, bypassing the shared cache is usually safer than varying on the entire Cookie header.

CDN caching versus browser caching

A CDN cache is shared and close to visitors. A browser cache is private and eliminates even the trip to the CDN while a response is fresh. The two layers can be controlled independently with s-maxage and max-age, though CDN-specific rules may augment or override origin behavior.

With Cloudflare Origin Cache Control enabled, origin Cache-Control directives generally guide edge behavior. Cloudflare Cache Rules can change edge and browser TTLs, eligibility, cache keys, and bypass conditions. Other CDNs provide similar controls with different defaults.

Useful diagnostic response headers include:

• Age: seconds the response has spent in a shared cache.
• CF-Cache-Status: Cloudflare cache outcome such as HIT, MISS, BYPASS, or DYNAMIC.
• X-Cache: a common vendor or proxy-specific cache status header.
• Via: intermediaries that handled the request.

A MISS followed by a HIT is a typical healthy sequence for cacheable content. Repeated misses can indicate an uncacheable response, a cache-key variation, eviction, a rule conflict, cookies, authorization, or an origin directive that prevents storage.

A cautious Nginx example

This example gives versioned static assets a long lifetime while requiring HTML revalidation. Adapt the file types and routing to the application.

location ~* \.(?:css|js|jpg|jpeg|png|gif|svg|webp|avif|woff2)$ {
    try_files $uri =404;
    add_header Cache-Control "public, max-age=31536000, immutable" always;
    access_log off;
}

location / {
    try_files $uri $uri/ /index.php?$args;
    add_header Cache-Control "no-cache" always;
}

Only use the one-year immutable policy when changing content also changes the URL. If files such as logo.svg are overwritten in place, reduce the lifetime or add versioned filenames.

Nginx proxy caching is a separate mechanism from response headers. Before enabling it for dynamic pages, define explicit bypass rules for authorization, login cookies, previews, carts, checkout, non-GET requests, and application-specific private routes.

A cautious Apache example

With mod_headers, Apache can set policy by filename. This example assumes static asset filenames are versioned:

<IfModule mod_headers.c>
  <FilesMatch "\.(css|js|jpg|jpeg|png|gif|svg|webp|avif|woff2)$">
    Header always set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>

  <FilesMatch "\.(html|htm)$">
    Header always set Cache-Control "no-cache"
  </FilesMatch>
</IfModule>

Apache mod_cache can also act as a shared caching layer, but it should be enabled carefully. Its quick handler can serve cached content early in request processing, so do not cache content protected by host-, address-, environment-, or application-level access logic without understanding the request path.

WordPress caching mistakes to avoid

WordPress can involve browser caching, a page-cache plugin, PHP OPcache, object caching, a server-level proxy cache, and a CDN simultaneously. Each solves a different problem.

• Page cache: stores complete rendered HTML for anonymous requests.
• Object cache: reuses database results and computed objects; it does not replace a page cache.
• OPcache: stores compiled PHP bytecode; it does not cache page output.
• CDN: usually caches static files and may cache public HTML when configured.

Never let shared caches mix anonymous and authenticated output. Exclude WordPress administration, login, previews, password-protected posts, carts, checkout, account pages, and responses with meaningful user-specific state. Purge affected page and edge caches when publishing or editing content.

For a broader view of these layers, see our guide to the fastest server stack configuration for WordPress.

How to debug HTTP caching with curl

First inspect the final response headers:

curl -ILs https://example.com/

Request the same cacheable asset twice and compare Age, CF-Cache-Status, X-Cache, ETag, and Last-Modified. To test an ETag manually:

curl -I https://example.com/assets/app.a91f4c2.css

curl -I \
  -H 'If-None-Match: "33a64df5"' \
  https://example.com/assets/app.a91f4c2.css

If the representation is unchanged and the ETag matches, the second request should return 304 Not Modified. A normal browser reload, hard reload, disabled-cache setting in developer tools, and back/forward navigation can behave differently, so use controlled requests when diagnosing the origin.

Common caching mistakes

• Treating no-cache as no-store: the former permits storage and requires validation.
• Caching personalized HTML publicly: this can expose one user’s content to another.
• Using immutable URLs without versioning: visitors may keep obsolete files until the lifetime expires.
• Setting long browser TTLs you cannot purge: purging a CDN does not remove a fresh response from every browser.
• Ignoring the cache key: query strings, hostnames, headers, cookies, and CDN rules may create separate entries.
• Using Vary: Cookie indiscriminately: it can destroy the shared-cache hit rate.
• Forgetting error and redirect responses: cached redirects or errors can persist after the underlying problem is fixed.
• Stacking conflicting rules: application, web server, plugin, hosting cache, and CDN settings may disagree.
• Purging instead of versioning assets: content-addressed filenames are more reliable than global cache purges.
• Measuring only the first request: a cold-cache MISS says little about steady-state cache performance.

A practical caching checklist

1. Classify every response as public, personalized, or sensitive.
2. Give every important response an explicit Cache-Control policy.
3. Use hashed filenames and long immutable caching for build assets.
4. Use validators for content that must remain current at a stable URL.
5. Keep personalized responses out of shared caches.
6. Document the cache key and bypass conditions at every shared layer.
7. Verify origin, reverse-proxy, CDN, and browser headers separately.
8. Purge page and edge caches when content changes, but prefer URL versioning for assets.
9. Monitor hit ratios, origin load, stale responses, and user reports after changes.

Frequently asked questions

Is browser caching the same as CDN caching?

No. A browser cache is private to one user. A CDN is a shared cache that can serve many users. Use max-age and s-maxage when they need different freshness lifetimes.

Should HTML use no-cache or no-store?

Use no-cache for ordinary non-sensitive HTML that may be stored but should be validated before reuse. Use no-store when storage itself is unacceptable because the response contains sensitive information.

Do I need both ETag and Last-Modified?

Sending both is useful when the server can generate them correctly. ETag provides a representation identifier, while Last-Modified remains useful to caches, crawlers, and other HTTP clients.

Why does my CDN keep returning MISS?

The response may be ineligible for caching, vary by cache key, contain cookies or authorization, be evicted, have an immediately stale policy, or match a bypass rule. Inspect the CDN status header, origin Cache-Control, request cookies, and active cache rules.

Does clearing a CDN cache clear browser caches?

No. A CDN purge removes edge copies but cannot remove fresh files already stored in visitors’ browsers. Change the asset URL when its contents change.

Final thoughts

Effective HTTP caching is a correctness policy first and a performance optimization second. Decide who may store each response, define its freshness, provide validators where appropriate, and ensure personalized content never enters a shared cache.

The most reliable general pattern is simple: version static asset URLs and cache them for a long time, keep stable HTML URLs easy to revalidate, and explicitly bypass shared caches for user-specific or sensitive responses. Then test every layer using the headers a real visitor receives.

Headers are defense in depth, not a substitute for secure code. They cannot repair broken authorization, vulnerable dependencies, unsafe database queries, or exposed secrets. They can, however, remove entire classes of avoidable browser behavior and make other vulnerabilities harder to exploit.

This guide explains the most useful headers, gives cautious starting configurations for Nginx and Apache, and shows how to test changes before enforcing them in production.

Security headers at a glance

1. Content-Security-Policy: control what a page may load

Content Security Policy, usually shortened to CSP, tells a browser which resource locations are allowed. It can restrict scripts, styles, images, fonts, frames, form destinations, network connections, media, workers, and other content. A strong CSP is one of the most valuable browser-side defenses against cross-site scripting and injected content.

A small baseline policy might look like this:

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests

This is a starting point, not a universal answer. It will block third-party scripts, styles, fonts, images, analytics, payment widgets, embedded videos, and API connections unless their sources are added to the appropriate directives. WordPress sites in particular may use inline styles, plugin scripts, external fonts, and administrative resources that require careful policy design.

Start with Report-Only

Do not paste a restrictive CSP into a busy production site and hope for the best. First send the same policy through Content-Security-Policy-Report-Only. Browsers will report violations without blocking the resources. Review the browser console and collected reports, identify legitimate dependencies, and refine the policy before switching to enforcement.

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"

For stronger script protection, mature applications should prefer nonces or hashes over broad allowances such as 'unsafe-inline'. A nonce must be unpredictable and generated separately for every response, so it normally requires application-level support rather than a static server directive.

2. Strict-Transport-Security: require HTTPS on future visits

HTTP Strict Transport Security, or HSTS, tells a browser that a hostname should only be accessed over HTTPS. After receiving the header on a secure response, the browser automatically upgrades later HTTP attempts and refuses to let the user click through certificate errors.

A production policy commonly looks like:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS is powerful because it persists in the browser. That persistence also makes mistakes painful. Before using includeSubDomains, verify that every current and future subdomain supports HTTPS correctly. Before requesting preload status, understand that removal is not immediate and ensure the entire domain is ready for a long-term HTTPS-only commitment.

A safer rollout is to begin with a short value such as max-age=300, monitor the site, increase it to a day or a week, and only then move to a year. Add includeSubDomains separately after auditing subdomains. Browsers ignore HSTS sent over HTTP, so configure the header on HTTPS responses and redirect plain HTTP traffic to HTTPS.

3. frame-ancestors and X-Frame-Options: prevent unwanted framing

An attacker can place a transparent or disguised version of a page inside a frame and trick a user into clicking its controls. This is known as clickjacking. The modern defense is CSP’s frame-ancestors directive:

Content-Security-Policy: frame-ancestors 'none'

Use 'self' instead if pages must be embedded by the same origin. Specific trusted origins can also be listed when framing is an intentional product feature.

X-Frame-Options: DENY provides a useful fallback for older browser behavior. Use SAMEORIGIN when same-origin framing is required. The obsolete ALLOW-FROM value is not a reliable way to permit selected origins; use CSP frame-ancestors for that purpose.

4. X-Content-Type-Options: stop MIME guessing

Browsers sometimes try to infer a resource’s type instead of strictly following its declared Content-Type. That behavior can turn incorrectly served content into executable script or HTML. The remedy is simple:

X-Content-Type-Options: nosniff

This header does not excuse incorrect MIME types. JavaScript must still be served with a JavaScript media type, CSS with text/css, and HTML with an appropriate content type and character encoding. Test uploaded and generated files carefully after enabling nosniff.

5. Referrer-Policy: limit information shared during navigation

The Referer request header can reveal the page a visitor came from. Depending on the policy, it may include a path and query string containing internal identifiers or other information that should not be sent to another site.

A balanced default for many public websites is:

Referrer-Policy: strict-origin-when-cross-origin

This preserves useful same-origin referrer information, sends only the origin on secure cross-origin requests, and sends no referrer when navigating from HTTPS to HTTP. Applications with stricter privacy requirements may choose no-referrer, while analytics-heavy sites should verify how a change affects attribution.

6. Permissions-Policy: disable browser features you do not use

Permissions Policy limits access to browser features in the current document and embedded frames. A site that never needs the camera, microphone, or geolocation can disable them explicitly:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=()

Do not blindly copy a very long feature list. Browser support and recognized directives evolve, and embedded applications may legitimately need selected capabilities. Begin with sensitive features you know the site does not use, then test payment flows, video calls, maps, file importers, and third-party frames.

7. Cookies and caching are part of the header review

Set-Cookie is not usually described as a security-header scanner category, but its attributes are critical. Session cookies should normally use Secure so they are sent only over HTTPS and HttpOnly so normal JavaScript cannot read them. Choose SameSite=Lax, Strict, or None according to the authentication and cross-site workflow. Cookies using SameSite=None must also use Secure.

Caching must also match the sensitivity of the response. Use Cache-Control: no-store when a response containing confidential data must not be stored. Remember that no-cache permits storage but requires revalidation before reuse; it is not equivalent to no-store.

A cautious Nginx configuration

The following example provides a reasonable starting structure. The CSP must be customized, and HSTS should remain disabled until HTTPS readiness has been confirmed.

# Send headers on error responses as well as successful responses.
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "DENY" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

# Test this policy with Content-Security-Policy-Report-Only first.
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests" always;

# Enable only after verifying HTTPS on the hostname and relevant subdomains.
# Start with max-age=300 before increasing the duration.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

The always parameter matters because otherwise Nginx sends add_header values only for selected response status codes. Also review header inheritance: defining any add_header directive inside a nested location can change which headers are inherited from a higher configuration level.

A cautious Apache configuration

Apache can set the same baseline through mod_headers. Place this in the relevant virtual host when possible, or in .htaccess when overrides are permitted.

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set X-Frame-Options "DENY"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests"

  # Enable only after a staged HTTPS readiness test.
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Apache maintains different internal header tables for ordinary and always behavior. If an application, proxy, or earlier rule already sets the same header, the browser may receive duplicates. Inspect the final response and unset an existing value before setting a replacement when necessary.

What about WordPress and Cloudflare?

For WordPress, prefer setting global security headers at the outermost reliable layer: the web server, reverse proxy, or CDN. Application code may not run for static files, cached pages, redirects, or server-generated error responses. A plugin or PHP hook can still be appropriate for dynamic, application-specific policies, especially a nonce-based CSP, but verify every response path.

Cloudflare response-header transform rules can add or replace headers at the edge. This is useful when origin access is limited, but it also introduces another configuration layer. Decide which layer owns each header. Avoid setting one CSP at the origin and a different CSP at the CDN, because multiple CSP headers are combined restrictively rather than allowing the union of both policies.

How to test HTTP security headers

Start with the response a real visitor receives, not only the server configuration file. A quick command-line check is:

curl -I https://example.com/

# Follow redirects and show the final response headers.
curl -IL https://example.com/

Then check several response types: the homepage, a normal content page, a redirect, a 404 page, an authenticated page, an API response, and representative static assets. Use browser developer tools to look for blocked resources and CSP console messages.

A focused scanner such as HeaderSec can provide a grade, prioritized findings, evidence, and remediation guidance after the manual check. Running a second scanner is useful because tools may weigh policies differently. Our comparison of the best SecurityHeaders.com alternatives covers options for header scanning, continuous monitoring, TLS analysis, and CI.

Common security header mistakes

• Enforcing CSP before observing: deploy Report-Only first and review legitimate violations.
• Adding unsafe-inline everywhere: this can remove much of CSP’s script protection. Prefer nonces or hashes when the application supports them.
• Preloading HSTS too early: confirm every subdomain and certificate process before making a hard-to-reverse commitment.
• Sending HSTS over HTTP: browsers accept it only from a secure HTTPS response.
• Breaking intentional embeds: choose frame-ancestors and X-Frame-Options values that match real framing requirements.
• Duplicating headers: origin, application, proxy, and CDN layers may each append their own value.
• Testing only HTTP 200: redirects, authentication errors, 404s, and 500 responses need appropriate protection too.
• Copying a scanner’s ideal policy blindly: the correct policy depends on the application’s assets, integrations, and threat model.
• Keeping obsolete headers: HPKP and Expect-CT should not be added to a modern baseline, and X-XSS-Protection is generally omitted or explicitly disabled in favor of CSP.

A practical deployment checklist

1. Inventory domains, subdomains, third-party assets, frames, APIs, and browser features.
2. Capture current production response headers from several URL and status-code types.
3. Add low-risk headers such as nosniff and an intentional referrer policy.
4. Deploy CSP in Report-Only mode and collect representative violations.
5. Refine and enforce CSP in stages, monitoring errors and business flows.
6. Roll out HSTS with a short max-age, then increase it after verification.
7. Add includeSubDomains only after auditing the entire namespace.
8. Retest from outside the origin so CDN and proxy changes are included.
9. Automate recurring checks to catch configuration drift.

Frequently asked questions

Which HTTP security header should I add first?

X-Content-Type-Options: nosniff is usually a low-risk first step if the site already serves correct MIME types. An intentional Referrer-Policy is also commonly straightforward. CSP and HSTS provide major benefits but require a staged rollout.

Will security headers stop all XSS attacks?

No. A strong CSP can reduce the exploitability of many injection flaws, but the application must still validate input, encode output, avoid unsafe DOM operations, and keep dependencies secure.

Should every site use HSTS preload?

No. Preload is appropriate only when the registrable domain and all subdomains are ready for permanent HTTPS enforcement and the team understands the operational commitment. Ordinary HSTS can be deployed without preload.

Why do two scanners give different grades?

Scanners use different rulesets, weights, browser assumptions, and opinions about legacy headers. Review the evidence behind each finding instead of optimizing only for a letter grade.

Final thoughts

A good security-header configuration is deliberate, observable, and owned by one clear layer of the stack. Begin with the controls that match the site’s real behavior, test CSP without enforcement, roll out HSTS gradually, and inspect the final response after every proxy and cache has handled it.

The goal is not to collect the largest possible set of headers. It is to give browsers a coherent policy that reduces risk without breaking legitimate users or application features.

We reviewed the current options in July 2026. The best SecurityHeaders.com alternative depends on whether you want a fast one-off check, developer-friendly automation, organization-wide monitoring, or a broader security assessment. The seven tools below cover those use cases without pretending that an automated header scan replaces a complete security review.

SecurityHeaders.com alternatives at a glance

1. HeaderSec — best overall SecurityHeaders.com alternative

HeaderSec is our top pick because it keeps the scan focused while providing more context for developers and operators. Enter a public URL, choose a fast or deep scan, and receive both a letter grade and a 0–100 header posture score. You can also bypass the cache when you need to confirm a recent configuration change.

The scanner checks controls related to HSTS, Content Security Policy, clickjacking, MIME sniffing, cookie attributes, cross-origin isolation, and avoidable information leakage. Results are separated into failed, warning, passed, and not-applicable groups. Instead of only listing missing headers, the report highlights priority fixes and includes evidence, remediation guidance, and reference links for individual findings.

HeaderSec also exposes useful request context. Reports show the requested and final URL, redirect chain, observed response headers, scan freshness, scanner version, and ruleset version. A shareable report link makes it easier to pass a finding to another developer or include it in a ticket.

For automation, the HeaderSec API supports bearer-token or x-headersec-api-key authentication. Authenticated scans are associated with a team and appear in dashboard history, while named keys can be created and revoked independently. A basic request looks like this:

export HEADERSEC_API_KEY="hsec_live_your_key_here"

curl -sS -X POST https://api.headersec.com/api/v1/scans \
  -H "authorization: Bearer $HEADERSEC_API_KEY" \
  -H "content-type: application/json" \
  --data '{"url":"https://example.com","force":true}'

Choose HeaderSec if: you want a direct SecurityHeaders.com replacement with clearer prioritization, multiple scan depths, reproducible fresh scans, and an automation path for scripts or CI jobs.

2. MDN HTTP Observatory — best free second opinion

MDN HTTP Observatory, developed by Mozilla, analyzes HTTP headers and other important web security configurations. It produces a score and detailed test results, making it a valuable independent second opinion after changing CSP, HSTS, framing, referrer, or content-type policies.

The Observatory also has a versioned scan API, which is helpful for lightweight automation. Its scope is intentionally centered on HTTP data. Mozilla’s documentation notes that the current service does not provide specific TLS and certificate analysis, so pair it with SSL Labs when transport security is part of the review.

Choose MDN HTTP Observatory if: you want a respected, straightforward header assessment backed by Mozilla guidance.

3. Hardenize — best for continuous perimeter monitoring

Hardenize goes beyond a one-time header grade. Its platform combines Internet asset discovery with continuous monitoring of certificates, network services, and security configuration. Public reports inspect HTTPS deployment, redirects, returned HTTP headers, HSTS, Content Security Policy, and related web controls.

This broader scope is valuable for organizations with multiple domains, subdomains, cloud accounts, and certificates. It can help detect drift and expiring or newly discovered assets rather than waiting for someone to remember to run another manual scan.

Choose Hardenize if: you need ongoing visibility across an Internet-facing estate, not just an individual page check.

4. ImmuniWeb Website Security Test — best broader assessment

ImmuniWeb Website Security Test combines header analysis with a wider non-intrusive review. Its documented coverage includes CSP, HSTS, framing, MIME sniffing, referrer and permissions policies, CORS, cross-origin policies, cache controls, reporting endpoints, cookie flags, Subresource Integrity, DNSSEC, CMS components, and WAF detection.

The report also includes security, privacy, and compliance-oriented signals and can be exported as a PDF. That makes it useful when a stakeholder wants one broad artifact rather than a narrowly scoped header grade.

Choose ImmuniWeb if: you want HTTP header findings inside a wider website security and privacy assessment.

5. Internet.nl — best for modern Internet standards

Internet.nl evaluates whether a website supports modern Internet standards. Its website test covers HTTPS, HTTP security options and security.txt, DNSSEC, IPv6, and RPKI. Reports include an overall percentage score, results by test section, improvement guidance, and a permanent report URL.

It is especially useful when header security is only one part of an infrastructure modernization effort. Internet.nl also provides batch testing and a dashboard for multiple domains, although the presentation is less focused on detailed per-header remediation than HeaderSec.

Choose Internet.nl if: you want a standards-focused view spanning web, DNS, addressing, and routing.

6. OWASP ZAP — best self-hosted option for CI

OWASP ZAP is an open-source dynamic application security testing tool rather than a hosted header grader. Its passive rules can flag missing or weak security headers while traffic is proxied or a target is crawled. Packaged Docker scans, GitHub Actions, an API, and the Automation Framework make it suitable for repeatable testing in a delivery pipeline.

ZAP’s baseline scan performs passive checks, while full and API scans can perform active testing. Only run active scans against systems you own or have explicit permission to test. The extra setup is worthwhile when you need to combine header checks with broader application findings and control where results are stored.

Choose OWASP ZAP if: self-hosting, pipeline integration, configurable policies, or full web application testing matters more than instant hosted results.

7. Qualys SSL Labs — best companion for TLS analysis

Qualys SSL Labs Server Test performs deep analysis of a public SSL/TLS server. It examines protocol and cipher support, certificates, key exchange, known weaknesses, and compatibility across simulated clients. The familiar letter grade makes transport configuration easy to compare over time.

SSL Labs is not a complete replacement for SecurityHeaders.com because TLS configuration and browser security headers solve different problems. It belongs in this list because it is the strongest companion check when the goal is to assess the security of the full HTTPS connection rather than only the response headers.

Choose SSL Labs if: your main concern is certificate and TLS configuration, or use it alongside HeaderSec for a more complete review.

How to choose the right security header scanner

Start with the operational question you are trying to answer. If a developer just changed a CSP or reverse-proxy configuration, a focused scanner with an uncached rescan and concrete evidence is the fastest path. If you manage many domains, continuous discovery and monitoring may matter more than a polished single report. For release gates, favor a tool with documented API behavior and stable machine-readable output.

• For the closest all-around replacement: start with HeaderSec.
• For a second scoring opinion: run MDN HTTP Observatory.
• For continuous external monitoring: evaluate Hardenize.
• For a broader website and privacy review: use ImmuniWeb.
• For DNS, IPv6, routing, and web standards: use Internet.nl.
• For self-hosted testing and CI: deploy OWASP ZAP.
• For certificates, protocols, and ciphers: add SSL Labs.

Whichever tool you choose, test the actual production response after CDN, proxy, load balancer, and application behavior have been applied. A header present in source configuration may be removed, duplicated, or overridden before it reaches a browser.

What a header grade does not tell you

A strong grade is useful evidence of defense in depth, but it does not prove that a website is secure. Automated header scanners generally do not validate authorization rules, business logic, database access, secret handling, dependency risk, server patching, or every path through an application. They may also disagree about deprecated headers, acceptable CSP sources, or whether a policy is appropriate for a particular application.

Treat the report as a prioritized configuration review. Confirm each recommendation in a staging environment, especially CSP and cross-origin changes that can break legitimate scripts, frames, APIs, or authentication flows. Then combine header checks with TLS testing, dependency scanning, application testing, monitoring, and manual review appropriate to the risk of the system.

Our recommendation

For most teams seeking a SecurityHeaders.com alternative, HeaderSec is the best place to start. It is focused enough for a quick check but detailed enough to guide remediation, and its fast/deep modes, cache bypass, evidence, priority fixes, redirect inspection, dashboard history, and API give it room to grow with a team’s workflow.

Pair it with SSL Labs when TLS matters, or with OWASP ZAP when you need broader application testing. For the core task of understanding and improving HTTP security headers, HeaderSec offers the strongest balance of clarity, developer usability, and automation.

Frequently asked questions

What is the best SecurityHeaders.com alternative?

HeaderSec is our best overall pick because it combines a focused header grade with priority fixes, evidence, remediation guidance, fast and deep scan modes, uncached rescans, dashboard history, and authenticated API access.

Can a security header scanner find website vulnerabilities?

It can identify missing or weak browser-facing controls and some configuration problems. It cannot replace a vulnerability scan, penetration test, code review, or architecture review.

Which tool should I use for CI/CD?

HeaderSec provides an authenticated scan API for scripts and CI jobs. OWASP ZAP is the better fit when you want a self-hosted scanner with configurable passive and active policies inside your pipeline.

The best Placehold.co alternative depends on what you need most: drop-in URL simplicity, long-lived caching, realistic photos, subject-based images, custom styling, or a broad choice of modern formats. We tested the services below in July 2026 and compared their documented features and live output.

Placehold.co alternatives at a glance

1. Plahold.com — best overall Placehold.co alternative

Plahold.com is our top choice because it preserves the best part of Placehold.co—a readable image URL—while adding a polished builder and production-oriented defaults. A size is all you need. Plahold returns SVG by default, so a basic placeholder is lightweight, crisp at any display size, and generated without a raster conversion step.

The API supports SVG, PNG, JPG, static GIF, WebP, and AVIF. You can set background and foreground colors, add custom text, choose from bundled popular fonts, request transparent backgrounds, and append @2x or @3x for high-density raster output. Documented dimensions run from 10×10 to 4000×4000 pixels, and invalid requests return small JSON errors instead of a mysterious broken image.

A basic example is https://plahold.com/i/800/. A customized hero image can be created with:

<img src="https://plahold.com/i/1200x630/102033/eafffb.svg?text=Preview" alt="Preview placeholder" width="1200" height="630">

Plahold also sends long-lived cache headers for deterministic URLs, which is useful when the same placeholder appears repeatedly in a development environment, documentation site, CMS preview, or visual test suite. The on-page URL builder makes it easy to choose dimensions, colors, text, fonts, scale, transparency, and output format without memorizing the syntax.

Choose Plahold if: you want the closest modern replacement for Placehold.co, need several current image formats, or prefer a fast SVG default with predictable URLs.

2. DummyImage.com — best for classic URL shortcuts

DummyImage.com is a long-running dynamic placeholder generator with a compact URL structure. It supports custom dimensions, foreground and background colors, and text. It also accepts aspect ratios such as 640x4:3 and includes named shortcuts for common screen and advertising sizes.

The format selection is more traditional than Plahold or Placehold.co: GIF is the default, with JPG and PNG also available. That is sufficient for many mockups, but it is less attractive when you specifically need SVG, WebP, or AVIF.

Example: https://dummyimage.com/600x400/102033/eafffb.png&text=Preview

Choose DummyImage if: you value familiar syntax, ratio-based sizing, and presets more than next-generation formats.

3. Lorem Picsum — best for realistic photo placeholders

Lorem Picsum takes a different approach. Instead of rendering text over a solid color, it returns real photographs at the requested dimensions. A simple URL such as https://picsum.photos/600/400 produces a random image, while an image ID or seed makes the result repeatable.

It also supports grayscale and adjustable blur filters, JPG and WebP file endings, an image-list API, and metadata endpoints. Seeded URLs are especially helpful for demos: the page looks realistic, but the same record can continue to show the same photo between refreshes.

Choose Lorem Picsum if: visual realism matters more than showing dimensions or labels inside the image.

4. FPOImg.com — best for gradients and multiline text

FPOImg is a strong option when flat gray rectangles make a prototype feel unfinished. It supports solid colors, named gradient presets, custom two-color gradients with an angle, custom captions, multiline text, automatic wrapping, and the option to hide the dimensions label.

Its browser generator is straightforward, and the resulting URL remains readable. For example, https://fpoimg.com/800x600?gradient=sunset&text_color=ffffff creates a more presentation-friendly placeholder than the typical gray box.

Choose FPOImg if: you want attractive gradients or multiline labels and do not need Plahold’s broad output-format selection.

5. Placehold.jp — best for CSS-style customization

Placehold.jp generates JPG and PNG images with configurable dimensions, font size, background color, text color, and custom text. Its unusual feature is an advanced CSS parameter, which can apply supported styles such as rounded corners to the generated image.

A normal image URL is simple: https://placehold.jp/24/102033/eafffb/600x400.png?text=Preview. The extra font-size segment makes it convenient when a label needs to remain readable across different placeholder sizes.

Choose Placehold.jp if: text sizing or CSS-like visual treatment matters more than SVG and modern raster formats.

6. LoremFlickr — best for subject-specific photo placeholders

LoremFlickr returns Creative Commons Flickr photos selected by dimensions and keywords. A URL ending in /technology, /dog, or a comma-separated group of terms can make a mockup’s imagery relevant to its content. The service also offers grayscale and color filters, plus a lock value that keeps a selected result stable while it remains cached.

There is an operational caveat. LoremFlickr has experienced Flickr API restrictions in the past. Its hosted service was working when we checked in July 2026, and the project also documents a self-hosted version for teams that want more control.

Choose LoremFlickr if: you need keyword-driven photos and accept the additional dependency on Flickr.

7. Placehold.net — best for ready-made placeholder artwork

Placehold.net focuses on reusable visual assets rather than a deeply parameterized text-image API. Alongside simple placeholders in common square, portrait, and landscape sizes, it offers avatar silhouettes, product boxes, map graphics, book covers, building images, and colorful abstract designs.

PNG and SVG options are available for some assets, and the site provides examples for responsive images and high-density displays. It is useful when a generic gray rectangle is too plain but random photography would distract from the interface.

Choose Placehold.net if: you want predesigned avatars, product images, or decorative placeholders with minimal setup.

How to choose the right placeholder image service

Start with the type of output your project needs. For deterministic UI blocks, documentation, and tests, use a service that encodes all important choices in the URL. For content-heavy mockups, a seeded or fixed photograph usually looks more convincing. If the placeholder will appear in demos seen by clients, gradients or ready-made artwork may be worth the reduced flexibility.

• For a drop-in Placehold.co replacement: start with Plahold.
• For modern formats: Plahold covers SVG, PNG, JPG, GIF, WebP, and AVIF.
• For realistic seeded photos: use Lorem Picsum.
• For keyword-based photography: use LoremFlickr.
• For gradients and multiline labels: try FPOImg.
• For classic presets and ratio shortcuts: choose DummyImage.
• For styled or predesigned assets: consider Placehold.jp or Placehold.net.

Also consider caching behavior, URL stability, format support, usage terms, and whether an external dependency is acceptable in production. Placeholder services are ideal during development, but important production interfaces should have an intentional fallback in case a third-party endpoint changes or becomes unavailable.

Our recommendation

For most developers looking for a Placehold.co alternative, Plahold.com is the best place to start. Its URL structure is easy to understand, its SVG default is efficient, and its support for transparent backgrounds, bundled fonts, retina scaling, and six output formats covers both quick wireframes and demanding prototype workflows. The visual builder also removes the trial and error from composing a custom URL.

Use Lorem Picsum or LoremFlickr when you specifically need photography. For conventional text-on-color placeholders, however, Plahold offers the strongest overall balance of simplicity, control, format coverage, and cache-friendly deterministic output.

Frequently asked questions

What is the best free Placehold.co alternative?

Plahold is our best overall pick for a free, no-signup placeholder image URL service. It offers a simple size-only default plus custom colors, text, fonts, transparency, retina scaling, and six output formats.

Which alternative is best for random photos?

Lorem Picsum is the easiest choice for random, fixed, or seeded photos. LoremFlickr is better when the image needs to match a keyword or topic.

Can I use placeholder images in production?

You can, but treat any externally hosted placeholder as a third-party dependency. Use deterministic URLs, specify image dimensions in your markup to reduce layout shifts, review the service’s terms, and provide a fallback for important production experiences.

The simplest option is the env object inside a debug configuration. Each key becomes an environment variable for the launched process, and each value should be a string.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Debug app",
            "type": "python",
            "request": "launch",
            "program": "${workspaceFolder}/app.py",
            "console": "integratedTerminal",
            "env": {
                "APP_ENV": "development",
                "API_BASE_URL": "http://localhost:8000",
                "DEBUG_SQL": "1"
            }
        }
    ]
}

Inside Python, read those values with os.environ or os.getenv(). Using os.getenv() is convenient when you want to provide a fallback for local development.

import os

app_env = os.getenv("APP_ENV", "production")
api_base_url = os.getenv("API_BASE_URL")
debug_sql = os.getenv("DEBUG_SQL") == "1"

print(app_env, api_base_url, debug_sql)

If you have many variables, avoid making launch.json too noisy. The Python debugger also supports an envFile setting, commonly pointing to a .env file in the workspace. This keeps launch configuration readable while still making variables available during debugging.

{
    "name": "Python: Debug with env file",
    "type": "python",
    "request": "launch",
    "program": "${workspaceFolder}/app.py",
    "console": "integratedTerminal",
    "envFile": "${workspaceFolder}/.env"
}

A matching .env file can look like this:

APP_ENV=development
API_BASE_URL=http://localhost:8000
DEBUG_SQL=1

Use env for a few debug-specific overrides and envFile for a larger set of local settings. If both are present, values set directly in env are useful for overriding values from the file in that specific debug configuration.

If a value is missing during debugging, first make sure you started the program with the intended launch configuration. Running the file with a different button or an extension command may bypass your configuration. Also restart the debug session after editing launch.json; environment variables are copied when the process starts, not while it is already running.

For multi-root workspaces, be careful with ${workspaceFolder}. It points to the selected workspace folder, so an envFile path that works in one folder may not exist in another. When in doubt, print the value in Python and confirm the debugger is loading the file you expect.

Do not commit real secrets to launch.json or .env. For passwords, tokens, and production credentials, use your operating system secret store, a deployment secret manager, or a local ignored file. A safe pattern is to commit an example file such as .env.example and keep the real .env out of Git.

A strong baseline is Nginx, PHP-FPM, MariaDB or MySQL, Redis, OPcache, and a page cache plugin or server-level cache. If Cloudflare or another CDN is available, use it for static assets, HTTP/2 or HTTP/3, compression, and edge caching rules where appropriate.

nginx + php-fpm + mariadb + redis + opcache + cloudflare

For PHP, use a current supported version and enable OPcache. OPcache keeps compiled PHP bytecode in memory, which reduces repeated parsing work on every request. These values are a reasonable starting point for a small to medium WordPress site, but memory limits should be adjusted to match the server.

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

At the web server layer, prioritize caching static files and passing only dynamic requests to PHP. Nginx can serve images, CSS, JavaScript, fonts, and cached files very efficiently.

location ~* \.(css|js|jpg|jpeg|png|gif|webp|svg|ico|woff2?)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
    access_log off;
}

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Redis object caching helps logged-in users, WooCommerce stores, dashboards, and plugin-heavy sites because repeated database results can be reused from memory. It does not replace full-page caching, but it complements it well.

For the database, keep slow query logging available, ensure tables use InnoDB, and avoid oversized autoloaded options. A bloated wp_options table can make every request slower even when the server stack looks healthy.

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY bytes DESC
LIMIT 20;

The fastest configuration is the one that matches real traffic. Measure time to first byte, cache hit ratio, PHP worker usage, database slow queries, and memory pressure before making aggressive changes. Start with safe caching and OPcache, then tune PHP-FPM workers, Redis, and database settings based on evidence.

Be careful with over-tuning. Too many PHP-FPM workers can exhaust RAM, and overly aggressive cache rules can serve stale pages to logged-in users or shopping carts. Change one layer at a time, then measure again.

For most WordPress sites, the biggest win is simple: serve cached pages to visitors, keep PHP fast for cache misses, and make MySQL do less repeated work.

In VS Code, the Python debugger reads its launch settings from .vscode/launch.json. To choose the directory your program should start in, set the cwd property on the debug configuration.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "cwd": "${workspaceFolder}"
        }
    ]
}

The value ${workspaceFolder} points to the root folder opened in VS Code. This is usually the best choice when your project has predictable folders like src, tests, data, or config. Your script will run as if you opened a terminal in the project root and launched Python from there.

If your script needs to run from a subdirectory, set cwd to that path instead. For example, a project with code under backend might use this configuration:

{
    "name": "Python: Backend app",
    "type": "python",
    "request": "launch",
    "program": "${workspaceFolder}/backend/app.py",
    "console": "integratedTerminal",
    "cwd": "${workspaceFolder}/backend"
}

You can confirm the working directory from inside Python by printing os.getcwd(). That small check is helpful when debugging path problems because it shows exactly what the debugger passed to the process.

import os
from pathlib import Path

print("cwd:", os.getcwd())
print("project file exists:", Path("data/input.csv").exists())

If the printed directory is not what you expected, update cwd and start a fresh debug session. Restarting matters because the working directory is chosen when the debugged process launches. Also check whether you opened the correct folder in VS Code; opening a parent folder or only the src folder changes what ${workspaceFolder} means.

For larger projects, avoid depending too heavily on whatever the current directory happens to be. A more reliable pattern is to build paths from a known file location using __file__ and pathlib. That makes your script more portable between VS Code, terminals, tests, cron jobs, and deployment environments.

from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent
input_path = BASE_DIR / "data" / "input.csv"

Use cwd when you need the debugger to match your normal command-line workflow. Use file-relative paths when the code itself should be independent of how it was launched. In practice, combining both habits makes Python debugging in VS Code much less surprising.

First, install PHPMailer with Composer if your project does not already include it. Composer keeps the library updated and gives you a clean autoloader.

composer require phpmailer/phpmailer

Then configure PHPMailer to use SMTP authentication. The account you use must be allowed to send mail through SMTP AUTH, and the mailbox should match the From address unless your Microsoft 365 tenant explicitly permits sending as another address.

use PHPMailer\PHPMailer\PHPMailer;
use PHPMailer\PHPMailer\Exception;

require __DIR__ . '/vendor/autoload.php';

$mail = new PHPMailer(true);

try {
    $mail->isSMTP();
    $mail->Host = 'smtp.office365.com';
    $mail->SMTPAuth = true;
    $mail->Username = 'sender@example.com';
    $mail->Password = getenv('OFFICE365_SMTP_PASSWORD');
    $mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
    $mail->Port = 587;

    $mail->setFrom('sender@example.com', 'Example App');
    $mail->addAddress('recipient@example.com');

    $mail->Subject = 'PHPMailer Office 365 test';
    $mail->Body = 'This message was sent through Office 365 SMTP.';

    $mail->send();
    echo 'Message sent';
} catch (Exception $e) {
    echo 'Mailer error: ' . $mail->ErrorInfo;
}

Do not hard-code the mailbox password in your PHP file. Use an environment variable, secret manager, or server-side configuration file outside the web root. This keeps credentials out of version control and makes rotation less painful.

If your app sends HTML mail, set both the HTML body and a plain-text alternative. The alternative body improves readability for clients that block or strip HTML.

$mail->isHTML(true);
$mail->Body = '
Your report is ready.
';
$mail->AltBody = 'Your report is ready.';

If authentication fails, check three common causes. First, SMTP AUTH may be disabled for the mailbox or tenant. Second, the account may require modern authentication or an app password depending on tenant policy. Third, conditional access rules may block sign-in from the server location.

For debugging, enable PHPMailer SMTP output temporarily. Avoid leaving this on in production because SMTP logs can reveal addresses and server details.

$mail->SMTPDebug = 2;
$mail->Debugoutput = 'html';

Office 365 also enforces sending limits and anti-abuse controls, so it is not a replacement for a bulk email platform. It works well for transactional messages such as password resets, contact form notifications, internal alerts, and low-volume application emails. For newsletters or marketing campaigns, use a dedicated email service with proper unsubscribe and bounce handling.

The safest tool is get_current_screen(). It returns a WP_Screen object that describes the current admin page. For a custom post type list table, the screen ID is normally edit-{post_type}, and the post_type property contains the post type name.

add_action('current_screen', function ($screen) {
    if (!$screen instanceof WP_Screen) {
        return;
    }

    if ($screen->id === 'edit-book' && $screen->post_type === 'book') {
        // You are on the admin list table for the "book" post type.
    }
});

If you want a reusable helper, wrap the check in a small function. This keeps conditions readable when the same logic is needed in multiple hooks.

function my_is_admin_post_type_list($post_type) {
    if (!is_admin()) {
        return false;
    }

    $screen = function_exists('get_current_screen') ? get_current_screen() : null;

    return $screen instanceof WP_Screen
        && $screen->base === 'edit'
        && $screen->post_type === $post_type;
}

You can then use the helper when enqueueing scripts or showing admin-only UI. The admin_enqueue_scripts hook is a common place for this because the current screen is already available.

add_action('admin_enqueue_scripts', function () {
    if (!my_is_admin_post_type_list('book')) {
        return;
    }

    wp_enqueue_script(
        'book-admin-tools',
        plugin_dir_url(__FILE__) . 'book-admin-tools.js',
        array('jquery'),
        '1.0.0',
        true
    );
});

Avoid relying only on $_GET['post_type']. It works in many cases, but it is less expressive and easier to misuse. For the default Posts screen, WordPress may omit post_type from the URL entirely. get_current_screen() gives you a normalized view of the admin page instead of making you reverse-engineer the request.

If the check runs too early, get_current_screen() may not be available yet. Put screen-dependent logic inside hooks such as current_screen, load-edit.php, or admin_enqueue_scripts. That keeps the code aligned with WordPress admin loading order and avoids false negatives during plugin initialization.

Also remember that admin list tables are not the same as front-end post type archives. On the front end, you would use conditional tags such as is_post_type_archive('book'). Inside wp-admin, use WP_Screen and check for the edit base plus the expected custom post type.

The fix is to use a non-interactive backend. The most common choice is Agg, which renders images in memory and writes them to files such as PNGs. It does not need a window manager, monitor, or running X server.

import matplotlib

matplotlib.use("Agg")

import matplotlib.pyplot as plt

x = [1, 2, 3, 4, 5]
y = [2, 5, 4, 8, 7]

plt.figure(figsize=(6, 4))
plt.plot(x, y, marker="o")
plt.title("Server-side Matplotlib chart")
plt.xlabel("Step")
plt.ylabel("Value")
plt.tight_layout()
plt.savefig("chart.png", dpi=150)
plt.close()

The important detail is the order. Call matplotlib.use("Agg") before importing matplotlib.pyplot. Once pyplot is imported, Matplotlib may already have selected a backend, and changing it later can be unreliable.

You can also set the backend outside the script by using the MPLBACKEND environment variable. This is useful when you do not want to modify application code, or when the same code runs in both local and server environments.

MPLBACKEND=Agg python generate_chart.py

In Docker or CI, this environment-variable approach keeps the container simpler because you do not need to install desktop packages just to export an image. Your Python dependencies can focus on the libraries required for rendering and data processing.

If you are troubleshooting an existing failure, check the error message for phrases like cannot connect to X server, no display name, or backend names such as TkAgg. Those are strong hints that the script is trying to use an interactive backend in a headless environment.

If your script generates many charts, remember to close figures after saving them. plt.close() releases memory associated with the current figure. Without it, long-running jobs can gradually consume more memory, especially when charts are created inside loops.

for name, data in reports.items():
    plt.figure(figsize=(8, 4))
    plt.plot(data["x"], data["y"])
    plt.title(name)
    plt.tight_layout()
    plt.savefig(f"{name}.png")
    plt.close()

Using Agg is best for saved image files, not interactive exploration. If you need to zoom, pan, or inspect plots visually, run the code on a machine with a graphical backend. For automated reporting, email attachments, dashboards, and scheduled exports, the non-interactive backend is usually the cleanest option.