Website Security and Hosting Checklist for Publishers

A secure site is the sum of small checks that depend on each other: hosting terms, certificates, backups, account access, firewall rules, browser headers and a plan for the day something fails. This checklist is for people who run a blog, a news site or a shop, and for small businesses choosing or auditing a host. It is written for defence and audit. How attacks are carried out is outside its scope; the aim is to close gaps and keep both visitors and search bots served without interruption.

Where security and search visibility meet

A security gap becomes a visibility problem as soon as the server stops answering. Google's documentation on HTTP status codes, network and DNS errors (Opens in a new tab) says that 5xx and 429 server errors make Google's crawlers slow down temporarily. For 500, 502 and 503 the slowdown scales with the number of individual URLs returning the error, and once the server returns 2xx again Google gradually raises the crawl rate. The same page says Google's indexing pipeline removes URLs that persistently return 500, 502 or 503: URLs already indexed are kept for a while, then dropped if errors continue, and content received with a 5xx response is ignored.

The reverse also holds. A protection that is set too tight can cause the same symptoms. A firewall rule that blocks Googlebot, a server overloaded by unthrottled requests, and a lapsed certificate each reduce what a visitor or crawler can reach. The page also says 4xx codes other than 429 do not affect crawl rate, so 401 and 403 should not be used to limit crawling. Security and search work are not two jobs; they share one measure, which is availability.

What this checklist leaves out

Cleaning a site that has already been compromised is a different task; see hacked site and SEO spam link cleanup. Penetration testing, compliance audits and legal duties are outside this topic.

Start by deciding what you are protecting

MDN's Web security (Opens in a new tab) page splits the field into attacks, defenses, threat modeling and authentication. It describes threat modeling as a structured process for identifying which threats a site faces and which defenses it needs. For a small publisher, that process can begin as a table: list what holds value, say what happens if it is lost or taken, and rank the protections.

A blog without sales will put the archive and domain first. A shop will put customer data and uptime beside them. The table takes half an hour to fill and sets the order of everything that follows.

Ten questions for a hosting provider

Naming brands without evidence would mislead, so the better tool is a list of questions that work with any provider, answered in writing.

Decision rule: treat every unanswered question as a risk line. If more than three stay open after the provider has had a chance to respond, compare alternatives before the next renewal.

Shared, virtual server or managed: who does what

The split varies between providers. What matters is getting the allocation into the contract or support thread. The thought that server security is the host's job hides the tasks that stay with you.

Certificates, HTTPS and the server basics

MDN lists HTTPS on all pages and subresources among its core practices. Two articles go deeper: renewal and monitoring are in expired SSL certificate renewal and automation, and what to check after moving to HTTPS is in mixed content and HSTS after an HTTPS migration.

Server software, closed unused services and file permissions depend on the type of hosting. On shared plans the provider handles them. On a server you manage, they are yours. Write down which case applies, so that "who updates the server" has one name as the answer.

Response time and caching

Slow responses hurt visitors and crawling. For the search effect of caching and CDNs, see TTFB, caching and CDN. For security the point is narrow: keep personal pages, admin screens and session-bound responses out of any public cache.

Domain and DNS records

The domain is the shared root of the site and its email. If the registrar account is taken over, the site can be redirected and mail can be read. Ask the registrar whether a registrar lock is offered, tie the account to a shared contact address, and research any DNS record whose purpose nobody can explain. Keep a change log of who edited DNS and when. Unused subdomain records deserve a cleanup as well, since neglected records create their own risk, described in the article on dangling DNS records and subdomain takeover.

Accounts, roles and secrets

MDN's authentication section covers passwords, one-time passwords, federated identity, passkeys and session management. In its summary of core practices it prefers passkeys, then time-based one-time passwords, over passwords alone. Its operational security entry covers protecting source code, handling secrets safely and managing dependencies.

Leavers and former agencies

Access that outlives a contract is a gap that is easy to forget. When a person leaves or an agency contract ends, review the access list on that day. Make it a checklist line, because memory fails.

Updates, backups and restore drills

Practical suggestion: treat updates, backups and restores as one routine. Updates, backups and restores belong together: if an update breaks something, the restore is the way out.

1. Try plugin and application updates on a staging copy first.
2. Store backups away from the server, in a separate account.
3. Once a quarter, perform a real restore and record how long it took.
4. Write down the date of the last good backup before every update.
5. Remove unused plugins, themes and old versions.

The intervals are examples. Choose them by how much data you can afford to lose.

WAF and rate limits: protection versus crawling

A web application firewall evaluates incoming requests against rules. Cloudflare's WAF documentation (Opens in a new tab) describes custom rules, managed rules and rate limiting rules. Custom rules let you write your own protections for a website and its APIs against malicious incoming traffic. Managed rules are pre-configured rulesets that are regularly updated and whose behavior can be adjusted. Rate limiting rules define limits for incoming requests that match an expression, plus the action to take once a limit is reached. The page also says Security Events lets you review mitigated requests and tailor security configurations based on sampled logs.

That is one vendor's documentation; other providers name features differently. The page points to its linked pages for the action list and any log-first approach.

Not blocking the wrong visitors

Practical suggestion: start a new rule in a mode that records its effect without enforcing it, read the log, then enforce. A rule that blocks bad traffic can block Googlebot too. How to verify Googlebot is in verifying Googlebot access when a WAF or CDN is in the way, and managing unwanted bots is in managing bad bot traffic.

Browser-side defences: HTTPS, CSP, cookies and SRI

MDN's core practices include: HTTPS for all pages and subresources; a Content Security Policy, ideally strict or at least one that disallows inline JavaScript; frame-ancestors for clickjacking protection; limiting cookie access with SameSite, Secure and HttpOnly plus short lifetimes for logged-in cookies; validating input and then encoding or sanitizing output; and Subresource Integrity for externally loaded scripts such as those from CDNs. The page also mentions the HTTP Observatory tool, which scans a site for good security practices.

Details of each header and how to roll it out are in the guide to HTTP security headers, CSP and Referrer-Policy.

Rollout order for headers

1. Confirm HTTPS and redirects.
2. Check cookie attributes.
3. Add low-risk headers and open the pages.
4. Start CSP in report-only form, read the reports and then tighten the policy.
5. Record each header, the date and the way back in a change log.

Input, output and sessions

MDN gives the order: validate input first, then encode or sanitize output. Forms, search boxes and comment fields are where this applies. With a ready-made CMS, the software does the bulk of the work and your job is to keep it and its plugins current and to check that a plugin is still maintained. For custom code, ask the developer in writing where validation and encoding are applied.

Third-party scripts and dependencies

MDN names supply chain attacks and recommends SRI for externally loaded scripts. Every analytics tag, ad snippet, chat widget or comment script runs code you do not control. Performance effects are treated in the article on auditing third-party scripts. For security, one rule is enough: each script has an owner, a purpose and a date on which it will be removed.

Keep one more discipline: write down what each rule and setting is for, in a sentence, the day you add it. Security settings that nobody can explain a year later are the ones that get switched off in a hurry during an outage, or left in place long after they stopped serving a purpose. A short purpose note next to each rule, header and account role makes the quarterly audit a ten minute review instead of an archaeology project, and it lets a new colleague or an agency understand the setup without a long handover call.

Monitoring and outages

Hearing about a problem from a customer is the worst way to find it. Set up an outside uptime monitor for the home page, the login page, the checkout page and one product page, reading status code and response time. Search Console's Crawl Stats gives a host status view of robots.txt, DNS and connectivity problems over the past 90 days.

For planned work, a 503 response with retry information is the correct signal; see hosting outage, 5xx errors and crawl impact.

An incident plan: who does what, and when

The plan has to work when one person is absent, so name a deputy for each stage and keep contact details somewhere reachable without the hosting panel.

Example scenario: a toy retailer and a security plugin

Example scenario: an online toy retailer installs a security plugin before the holiday season and switches on its strictest firewall preset. A week later, new product pages stop appearing in search. The owner suspects an algorithm change. The checklist leads somewhere else: the Crawl Stats host status and response table show a rising share of 403 and 5xx answers to Googlebot, and the rule log shows that an automated rule is challenging crawler requests as if they were scrapers. The fix is not a rewrite of the site. The preset is moved to monitor mode, a rule is added that lets verified Googlebot through, and the setting is recorded in the change log.

The same week reveals a second gap. The seasonal freelancer who helped with the shop still has an active administrator account, and the registrar account sits behind a personal mailbox. Neither gap caused trouble this time, but both appear in the first two rows of the priority table. The retailer closes them, schedules a restore drill, and writes the incident plan. The lesson is that one tool installed in a hurry can cause a visibility problem while quietly leaving ordinary gaps untouched.

When a protection works against you

A control that is switched on and never reviewed can cause the outage it was meant to prevent. For each control, know how it fails and how you would notice.

Practical suggestion: change one control at a time and record the date, so a later rise in errors can be tied to a single change.

Decision rule for a security change that coincides with errors

Decision rule: if a new rule appears on the same day that 403, 429 or 5xx answers to crawler requests rise, return the rule to monitor mode first and investigate second. Visitors and search bots both depend on being served, and a rule you can switch back in a minute is cheaper than a week of lost crawling.

Misconception worth correcting: "more rules mean more safety". Each rule adds a place where a legitimate request can be refused, so every rule needs an owner, a reason and a review date.

A quarterly audit calendar

Twenty-point checklist

• Certificate renewal is automatic and monitored.
• All pages and subresources load over HTTPS.
• Backups are stored away from the server and a restore was tested.
• Two-step verification is on for every admin account.
• Former employee and agency access is closed.
• Software versions have a named owner for updates.
• WAF and rate limit rules are tuned from log data and reviewed.
• Googlebot access was verified after security rules changed.
• CSP and other headers were first tried in report-only or monitor mode.
• Cookies carry SameSite, Secure and HttpOnly.
• External scripts are listed, with SRI where possible.
• Outside uptime monitoring is on.
• Maintenance returns 503 with retry information.
• The incident plan names roles and deputies.
• Unused subdomain records were removed.

Which gaps to close first

Decision rule: if more than five of the checklist lines are missing, close account access, backups and certificates first, since those three lead directly to outages and data loss. The order is a practical suggestion; change it if your asset table ranks things differently.

Frequently Asked Questions

Do security settings affect SEO?

Indirectly, yes. Google's documentation says 5xx and 429 errors slow crawling temporarily and that URLs persistently returning 500, 502 or 503 can be dropped from the index. A badly configured firewall rule can produce those results.

What is a WAF and does a small site need one?

A WAF evaluates incoming requests against rules. Cloudflare's documentation describes custom rules, managed rulesets and rate limiting rules. Whether you need one depends on your risk and on what your host already provides.

Can a rate limit block Googlebot?

It can if it is set badly. Try the rule in a monitoring mode first and confirm in the logs that Googlebot requests are not affected.

Which security headers should I add?

MDN lists practices such as CSP, cookie attributes and SRI for external scripts. Try headers in report-only mode first and open the home, login and checkout pages by hand afterwards.

What should I look for when choosing a hosting provider?

Ask where backups live and whether a restore was tested, who manages certificates, who updates software, what happens at resource limits, how the panel is protected, how long logs are kept and how fast support responds.

Will this checklist fix a site that has already been hacked?

No. It is preventive. A compromised site needs a separate cleanup process.

Conclusion

Security, hosting and search visibility share one aim: the site answers visitors and search bots correctly, quickly and without interruption. Work through the checklist by layer, close the direct risks of account access, backups and certificates first, then add WAF rules, headers and third-party script controls. Test each new rule in a monitoring mode, and verify Googlebot access after every change to security settings.

To support the authority of a site with a solid infrastructure, take a look at our backlink packages.