TLS and WordPress security: the controls that work together

This guide is a review plan for the site owner and technical team. Server configurations vary, so copying a large hardening block from another site without testing is not a safe shortcut.

Establish the connection path

List the public hostnames and where each connection terminates. A CDN or reverse proxy may sit in front of the origin server. Check how the proxy communicates with the origin and how WordPress determines that a visitor is using HTTPS.

Confirm the certificate covers the intended names, is served with the required chain and renews successfully. Use the certificate guide if you need the underlying concepts. An edge certificate alone does not prove that every part of the path is configured correctly.

Use a maintained TLS configuration

Review protocol and cryptographic settings against current guidance for your server and supported clients. Avoid old SSL protocols and obsolete configurations. Keep the TLS implementation itself supported and updated.

TLS protects the connection in transit, while application security addresses what happens behind it. It cannot prevent an authorised but compromised account from changing content. MDN's TLS explanation.

Run an appropriate public TLS check, then interpret the findings. A score is useful evidence about the tested connection, not a general security guarantee. Record the hostname and date so the result can be compared after changes.

Redirect consistently and remove mixed content

Choose the canonical HTTPS hostname and ensure the alternatives reach it sensibly. Avoid redirect loops between a proxy and WordPress. Update relevant application settings and internal URLs through the site's normal change process.

Check images, scripts, stylesheets, forms and embedded resources. A page that loads over HTTPS may still refer to resources using HTTP. Test the browser console and the visible customer journey, especially older content and third-party integrations.

For a domain or hosting move, preserve the previous URL mapping and verify redirects alongside the WordPress migration checklist.

Introduce HSTS deliberately

HSTS tells a browser to use HTTPS for a host on future requests. The includeSubDomains option extends that policy to subdomains, which can affect services outside the main website. Review every affected hostname before enabling broad or long-lived policies. MDN HSTS documentation.

Do not automatically add preload because it improves a scanner result. It is a separate commitment with operational consequences. First confirm that the relevant services can consistently meet the policy and that someone owns future changes.

Treat security headers as application changes

Content Security Policy can restrict sources the browser loads and help reduce the impact of some injection attacks. Its effectiveness depends on the policy. A copied permissive header can provide little protection, while an overly strict one can break forms, payments or administration.

Use a staged approach, often starting with reporting, review expected resources and test the full site before enforcement. Reporting alone does not block violations. MDN CSP guide.

Other headers also need context. Review framing requirements, content-type handling and referrer exposure with the application owner. A missing header should prompt investigation rather than an automatic conclusion that the site has been breached.

Maintain WordPress behind the connection

Keep an inventory of plugins and themes, remove unused components and follow relevant advisories. Back up before changes and test important functions after updates. The official WordPress hardening guide covers broader application and environment considerations.

Use individual accounts, appropriate privileges and strong authentication. Protect administrative access and keep the recovery route documented. Our update guide provides the day-to-day sequence.

Verify the whole release

Check the homepage, important landing pages, login, forms and checkout if present. Test mobile behaviour and external integrations. Confirm that certificate renewal and monitoring still work after DNS or proxy changes.

Keep a backup of the previous configuration and a rollback plan for the application changes. HSTS and other browser-cached behaviour can outlive a simple server rollback, which is why planning matters.

ResaHost website security and WordPress maintenance put these tasks within an agreed technical responsibility. Ask what is included and how changes are verified; do not mistake a promise of a perfect score for a maintained service.