What are website headers?
Website headers are metadata sent between a browser and a server when someone requests a page, file, API route, or asset.
The visible page is only the body of the response. Headers are the rules around it.
They can answer questions like:
- Did this URL return successfully?
- Was the user redirected?
- Should this page be indexed?
- How long should this file be cached?
- Is the response compressed?
- What security policies apply?
- Is the canonical URL clear?
- Did the CDN or hosting layer change the response?
For custom websites, headers often come from several places at once: the application, the CMS, the hosting provider, the CDN, middleware, redirects, edge functions, and sometimes third-party scripts. That is exactly why they need to be checked as a system.
Why header checks matter before launch
Header mistakes rarely announce themselves in the UI.
A stakeholder can review a page visually and miss the fact that it returns a 302 instead of a 301, sends a noindex directive, caches a preview version, or blocks an important script with an overly broad security policy.
Header QA protects four launch outcomes.
1. Search engines can understand the site
Search engines use more than visible page content. Status codes, redirects, canonical signals, robots directives, and response consistency all affect crawl behavior.
If the wrong header ships, the site can be technically live but strategically invisible.
2. Users get the right version of the site
Caching headers influence whether users see fresh content or stale content. CDN behavior can also differ by path, file type, geography, or device.
That matters during launches, migrations, pricing updates, product announcements, and homepage changes.
3. Analytics and conversion tracking stay trustworthy
Header issues can affect script loading, redirect chains, page paths, cookie behavior, and event reliability. If measurement breaks during launch week, you lose the cleanest window for understanding what changed.
Do not spend custom-website money and then measure the launch with a shrug.
4. Security and compliance basics are not accidental
Security headers are not a substitute for secure engineering, but they are part of the baseline. They reduce avoidable browser-side risk and show whether the launch process included more than visual approval.
The launch header checklist
Use this checklist before launch, after deployment, and again after DNS/CDN changes. Some headers can look correct in staging and change in production.
| Check | What to verify | Why it matters |
|---|---|---|
| Status codes | Key pages return 200; removed pages return 404 or 410; redirects return the intended status | Prevents crawl confusion and broken user paths |
| Redirects | Redirect chains are short, permanent where appropriate, and point to final canonical URLs | Protects SEO equity and user experience |
| Canonical behavior | Final URLs resolve consistently with one preferred version | Reduces duplicate-content and tracking noise |
| Robots directives | No accidental noindex, nofollow, or staging restrictions | Keeps public pages indexable |
| Caching | HTML, assets, feeds, and API routes use the right cache rules | Prevents stale content and performance regressions |
| Compression | Text assets are compressed where appropriate | Improves load performance |
| Security headers | Baseline browser protections are present and compatible with the site | Reduces preventable risk |
| Analytics scripts | Headers and policies do not block scripts or cookies required for approved tracking | Keeps launch data usable |
| CDN response | The edge response matches the application response | Catches hosting/CDN configuration drift |
Check status codes first
Status codes are the simplest header signal and one of the easiest to get wrong during a redesign or migration.
Before launch, check the important paths:
- Homepage
- Service pages
- Pricing or consultation pages
- Blog index
- Top blog posts
- Case studies
- Legal pages
- Sitemap
- Robots file
- High-value legacy URLs
The goal is not just “does it load?” The goal is: does the correct URL return the correct response with the correct intent?
A few practical rules:
- Use 200 for live, indexable pages.
- Use 301 for permanent redirects.
- Avoid unnecessary 302 redirects unless the move is temporary.
- Use 404 or 410 for pages that should be gone.
- Do not let soft 404 pages return 200 just because they have a branded error design.
A beautiful error page with the wrong status code is still a bug. It is just wearing better clothes.
Verify redirects and canonical paths
Redirects are where launch problems compound.
One redirect is usually fine. Three redirects, mixed protocols, trailing slash inconsistencies, and query strings that mutate halfway through the chain are a different story.
For each important path, verify:
- HTTP redirects to HTTPS.
- www and non-www behavior is intentional.
- Trailing slash rules are consistent.
- Old URLs map to the most relevant new URLs.
- Redirects do not pass through staging, preview, or temporary domains.
- UTM parameters are preserved where needed.
- Final URLs match canonical expectations.
This is especially important for custom website builds where the new information architecture differs from the old site. A redirect map is not a spreadsheet artifact. It has to be tested against the live response.
Look for accidental noindex directives
A single noindex directive can make a finished page disappear from search results.
Check both places where indexing instructions commonly appear:
- HTML meta robots tags
- X-Robots-Tag response headers
The X-Robots-Tag header is easy to miss because it does not appear in the visible page content. It can also apply to PDFs, images, feeds, and other files.
Before launch, confirm that public pages do not carry accidental noindex rules from staging. Also confirm that pages meant to stay private, thin, duplicated, or transitional are handled intentionally.
Indexation should be a decision. Not a leftover setting.
Review caching headers by content type
Caching is one of the places where “best practice” gets people into trouble.
There is no single cache rule that fits every asset. A custom website usually needs different rules for:
- HTML pages
- CSS and JavaScript bundles
- Images
- Fonts
- API responses
- RSS feeds
- Sitemap files
- Preview or draft routes
Static assets can often be cached aggressively when filenames are versioned. HTML usually needs more care because the content changes and marketing teams need confidence that updates will appear when published.
Before launch, check headers such as:
- Cache-Control
- ETag
- Last-Modified
- CDN-specific cache headers
- Revalidation behavior after content updates
The real test: publish or update content, then confirm the public site shows the new version without requiring weird browser rituals.
If the launch plan includes “tell everyone to hard refresh,” the launch plan is not done.
Confirm compression and asset delivery
Compression headers help confirm that text-based assets are being delivered efficiently.
Check whether HTML, CSS, JavaScript, JSON, and SVG files use compression such as Brotli or gzip where appropriate. Also check that large assets are served from the expected CDN or optimized delivery layer.
This is not only about speed scores. It is about avoiding waste. If the site ships custom design and development, the delivery layer should not behave like an afterthought.
Check security headers without breaking the site
Security headers should be part of launch QA, but they need to be handled carefully. Overly strict policies can break scripts, embeds, analytics, forms, or payment flows.
Common headers to review include:
- Content-Security-Policy
- Strict-Transport-Security
- X-Content-Type-Options
- Referrer-Policy
- Permissions-Policy
- Frame-Options or equivalent frame rules
The goal is not to paste a generic security-header template into production. The goal is to define policies that fit the actual site.
For example, a B2B SaaS website may need approved analytics, CRM forms, scheduling embeds, product videos, chat widgets, or documentation assets. The security policy should allow what the business uses and block what it does not.
Test headers from production, not only staging
Staging is useful. It is not proof.
Production can differ because of:
- DNS behavior
- CDN configuration
- Edge middleware
- Environment variables
- Hosting rules
- Preview-mode guards
- CMS webhooks
- Domain-level redirects
- Security policies applied outside the app
Run header checks against the real production domain after deployment. If DNS is changing, run them again after propagation. If a deploy hook rebuilds static pages, verify after the rebuild, not before.
This is the difference between “we checked the code” and “we checked the website users will actually visit.”
How to run a practical header QA pass
You do not need to turn every stakeholder into a developer. You do need a repeatable process.
A good header QA pass looks like this:
- Build a list of priority URLs.
- Include both new URLs and legacy URLs.
- Check status codes and redirect chains.
- Verify indexation directives.
- Confirm canonical paths.
- Review caching by content type.
- Confirm compression and CDN behavior.
- Test security headers against real third-party scripts.
- Confirm analytics and conversion events still fire.
- Document exceptions so future maintenance is easier.
The last point matters. Header decisions should not live only in a developer’s memory. If the site has unusual cache rules, redirect behavior, or security-policy exceptions, document why.
That is how a custom website stays maintainable after launch.
What founders and marketing teams should ask their web partner
You do not need to inspect every header yourself. But you should know what to ask before approving launch.
Ask these questions:
- Have we checked production response headers for priority pages?
- Are old URLs redirecting to the right new URLs?
- Are any public pages carrying accidental noindex directives?
- Do caching rules support both performance and content updates?
- Are analytics, form, CRM, and scheduling scripts allowed by the security policy?
- Does the CDN response match what the application is sending?
- Did we retest after the deploy hook, DNS change, or CMS publish event?
- Are the exceptions documented for future maintenance?
These questions are not micromanagement. They are launch risk management.
Header checks are part of full-stack quality
Custom design gets the attention because people can see it.
Header quality gets ignored because people only notice it after something breaks.
For a premium website, both matter. The interface should be clear, credible, and conversion-focused. The underlying system should also be legible to search engines, safe for browsers, predictable for caching, and measurable for the team making decisions after launch.
That is the point of full-stack custom design and development: the visible experience and the operational details are built together.
Not duct-taped together in the final week.
Frequently asked questions
What is the most important header check before launch?
Start with status codes, redirects, and accidental noindex directives. Those issues can affect whether users and search engines reach the right pages. After that, review caching, security headers, compression, CDN behavior, and analytics compatibility.
Do header checks matter for non-technical marketing sites?
Yes. Marketing sites still depend on redirects, indexing, analytics, security policies, caching, and CDN delivery. A site does not need complex app logic to have header problems that affect search visibility, conversion tracking, or launch confidence.
Should every custom website use the same security headers?
No. There are baseline protections most sites should consider, but the exact policy should fit the site’s scripts, embeds, forms, analytics, and hosting stack. A copied policy can either leave gaps or break legitimate functionality.
When should header QA happen?
Run it before launch, immediately after production deployment, and again after DNS, CDN, CMS, or hosting changes. Staging checks are useful, but production headers are the source of truth for users and search engines.
Ready to launch without guessing?
Virdis builds custom websites where design, development, SEO, performance, and maintainability are treated as one system.
If your next launch needs more than a nice-looking page, bring us in before the final week gets weird.
