# Fix website health basics

> Keep transport, DNS, browser policies and linked files working.

By Joey Kudish · Published 2026-10-31

These are website and domain maintenance checks. Some help pages load and work reliably; others protect email or certificate issuance. DNS and mail hygiene alone do not decide whether an AI engine mentions your business.

Take a copy of existing DNS and server settings before changing them. Test in staging where possible. DNS changes can take time to propagate, and a cached result is not proof a new setting has reached every resolver.

<h2 id="dnssec">DNSSEC</h2>

DNSSEC signs DNS responses so a validating resolver can check them. A broken signing chain can make the domain stop resolving for those users.

Follow your DNS provider and registrar's instructions together. Confirm the zone is signed before publishing the corresponding DS record at the registrar. Verify validation after propagation. Keep a recovery plan for mismatched keys. Cloudflare's [DNSSEC explanation](https://www.cloudflare.com/learning/dns/dnssec/how-dnssec-works/) describes the chain. This is domain security, not an AI visibility score.

<h2 id="caa">Certificate authority permissions (CAA)</h2>

CAA records restrict which certificate authorities may issue certificates for a domain. An incorrect policy can break automatic certificate renewal.

List the authorities your host and CDN actually use, including wildcard needs. Confirm their expected CAA values before editing DNS. Test issuance and renewal after the change. Do not copy another site's issuer list. [RFC 8659](https://www.rfc-editor.org/rfc/rfc8659) defines CAA behavior and inheritance.

<h2 id="spf">Authorized email senders (SPF)</h2>

SPF describes authorized email senders. Multiple policies or permissive rules can weaken that signal. This does not control whether a crawler can read your pages.

Inventory your actual mail providers, then maintain one SPF record. Respect the lookup limit and include legitimate transactional and support mail. Check the provider's documented values rather than guessing. Send test messages before tightening policy. [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208) defines SPF and its limits.

<h2 id="dmarc">Email authentication policy (DMARC)</h2>

DMARC applies a policy to messages that fail aligned authentication. Monitoring and enforcement serve different stages of a mail rollout; moving straight to rejection can discard legitimate mail.

Check SPF and DKIM alignment for every sender. Collect reports, investigate failures, then choose a policy appropriate to your traffic. Keep report destinations under your control. A visible DMARC record is not a deliverability guarantee. [RFC 7489](https://www.rfc-editor.org/rfc/rfc7489) documents the policy and reporting model.

<h2 id="hsts">HTTPS enforcement (HSTS)</h2>

HSTS asks browsers to use HTTPS on future visits. It can protect transport, but a long-lived policy is difficult to undo quickly if HTTPS breaks.

Verify certificates and HTTPS redirects first. Start with a short test lifetime, then extend it once the setup is stable. Only add `includeSubDomains` when every covered host supports HTTPS. Treat preload as a separate commitment. [MDN's HSTS reference](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security) explains those consequences.

<h2 id="mixed-content">Mixed HTTP and HTTPS content</h2>

An HTTPS page that references HTTP images, scripts, styles or form targets mixes secure and insecure transport. A browser may upgrade or block requests. A static reference check cannot prove what a browser eventually did.

Replace references with working HTTPS URLs. Verify the same asset is served and keep submission endpoints secure. Remove unavailable dependencies rather than disabling browser protections. Reload the page with the network and console panels open. [MDN's mixed-content guide](https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content) explains the resource types.

<h2 id="security-headers">Security headers</h2>

Headers such as Content Security Policy and Referrer Policy constrain browser behavior. Merely having a header does not mean its policy is effective.

Choose policies for the scripts, embeds and navigation your site actually needs. Test CSP in report-only mode before enforcement. Use `nosniff` with correct media types, and decide who may embed your pages. Recheck forms, analytics and payments after changes. Start with [MDN's header reference](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers); get a security review for policy effectiveness.

<h2 id="caching">Browser and CDN caching</h2>

Cache headers tell browsers and shared caches when they can reuse a response. Public pages can often be cached, but account pages and personalized content need different rules.

Separate public and private response policies. Choose a lifetime and invalidation path that fit how often content changes. Test a fresh response, a cached response and a post-update response. Never trade customer privacy for speed. [MDN's caching guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching) explains `Cache-Control`, validators and shared caches.

<h2 id="compression">Text compression</h2>

Text compression reduces transfer size. The Scan tests one negotiated gzip response; it does not establish whether every resource is compressed or whether Brotli is configured.

Enable suitable compression at your server or CDN. Send `Content-Encoding` only when the body uses that encoding, and vary on `Accept-Encoding` where needed. Test both compressed and ordinary requests. Do not recompress already compressed images without a reason. [MDN's compression guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Compression) explains the layers.

<h2 id="broken-links">Broken links</h2>

A checked `404` or `410` destination is broken. Timeouts, refused probes and untested links remain unknown. The counts refer to known sampled targets, not your whole site.

Find the source link and replace it with the intended working page, or remove it if there is no useful destination. When a page moved, use a specific redirect rather than sending everything to the homepage. Test the source and destination after publishing. Our [access guide](/guides/scan-access#soft-404) explains truthful missing-page responses.

<h2 id="broken-resources">Missing images, scripts and styles</h2>

A missing image, stylesheet or script can break what a visitor sees. The Scan counts observed missing resources separately from failed collection attempts.

Restore the intended file or correct the source reference. Check filename case, build output and CDN paths. Reload with the browser cache disabled and inspect layout and behavior, not only HTTP status. A replacement returning `200` with an HTML error page is still the wrong resource.