
WordPress Security Headers with .htaccess: HSTS, CSP and More
Deploy WordPress security headers through .htaccess without breaking checkout, the editor, embedded services or subdomains.
.htaccess is a plain text file in your site’s root that the web server reads on every single request. It is the reason permalinks work, and it is the fastest way to break a site completely — a stray character produces a 500 error on every page at once, dashboard included.
That combination is why these guides begin with orientation rather than rules. What the file is, what the block WordPress manages inside it does, how the server reads it, and how to take a copy you can put back before you change anything.
From there, the rules worth having. Forcing https, choosing between www and non-www, adding cache headers for static files, and the security headers that tell browsers how strictly to treat your pages.
Another group hardens specific things: stopping directory listings from exposing folder contents, keeping wp-config.php out of reach, blocking XML-RPC if you do not use it, and preventing other sites from embedding your images and billing you for the bandwidth.
The rest is recovery, because everyone breaks this file eventually. A 500 error after an edit, permalinks returning 404 when the WordPress block goes missing, a file the server will not let you write to.
Start with the beginner’s guide to the file even if you have edited it before. It covers the rollback habit that makes everything else here safe to try.

Deploy WordPress security headers through .htaccess without breaking checkout, the editor, embedded services or subdomains.

Set browser cache headers by resource type, using long lifetimes for versioned static assets without caching private or fast-changing WordPress responses.

Reduce unwanted image hotlinking without blocking your CDN, search previews, feeds, partners or visitors who send no Referer header.

Block access to xmlrpc.php only after confirming that Jetpack, mobile publishing and other remote clients do not depend on it.

Deny web access to wp-config.php and remove downloadable backup copies while preserving normal WordPress bootstrap access.

Disable Apache directory indexes without blocking legitimate WordPress media and static files.

Diagnose WordPress permalink 404s by comparing query-style URLs, rewrite rules, document roots and Apache override support.

Choose one canonical WordPress hostname and write an exact .htaccess redirect that preserves paths without creating loops.

Force HTTPS in WordPress only after TLS is ready, with one redirect owner and proxy-aware scheme detection.

Create an identifiable .htaccess backup and prove that it can restore both site access and the rules the file protects.