How to Add Custom Headers to a Zip-Hosted Site

Short answer: a ZIP deployment contains website files, not web-server configuration. On ZipHost today, adding _headers, .htaccess, or an nginx.conf file to your ZIP does not change the HTTP response headers sent by the platform. Do not rely on those files for security or caching rules.

This guide explains the difference between browser metadata and HTTP headers, shows what you can safely control in a static project, and gives you a repeatable way to check the live result before sharing a URL.

What counts as a custom header?

An HTTP header is sent by the server before the page body. Examples include Cache-Control, Content-Security-Policy, X-Frame-Options, and Access-Control-Allow-Origin. Browsers use these rules before they parse your HTML, so an HTML tag cannot substitute for every header.

Browser request
       ↓
Server sends: HTTP status + response headers + HTML file
       ↓
Browser applies header rules, then reads the page

What ZipHost controls and what your ZIP controls

Need	Can a ZIP file set it?	What to do
HTML title and description	Yes	Edit `index.html`.
Responsive viewport	Yes	Add a `meta name="viewport"` tag.
Browser caching policy	No	Use versioned asset filenames; request a platform-level header feature if you need exact policy.
Security headers	No	Use HTML controls where appropriate; use a proxy or a server product for strict header policies.
CORS response headers	No	Configure CORS at the API that owns the data, not in the static site ZIP.
Redirects	No	Use a normal link, an HTML redirect where suitable, or configure redirects outside the ZIP.

Do not upload these files expecting them to work

These files are valid on some other hosts, but ZipHost does not read them as deployment instructions:

_headers          # a convention used by some static hosts
_redirects        # a convention used by some static hosts
.htaccess         # Apache-only configuration
nginx.conf        # server administrator configuration

They may simply be served as files or ignored. They do not give a visitor permission to alter the shared web server.

What you can do inside `index.html`

For page-level controls, add standard metadata to the <head>. This is useful for search previews, mobile rendering, referrer behavior, and a basic CSP fallback. It is not a replacement for server-side security headers.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <meta name="description" content="A concise description of this page.">
  <meta name="referrer" content="strict-origin-when-cross-origin">
  <meta http-equiv="Content-Security-Policy"
        content="default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self'">
  <title>My site</title>
</head>

Test a restrictive CSP carefully. If your site loads a font, analytics script, embedded video, or API from another domain, add only the specific source it needs. A policy copied from another project can break your page.

Use hashed filenames when you need reliable updates

Because a static ZIP cannot set an exact Cache-Control policy, make changed assets look like new files. Instead of replacing app.js, publish a new filename such as app.84b7e2.js and update the HTML reference. Browsers then request the new URL instead of guessing whether an old file changed.

<link rel="stylesheet" href="/assets/site.84b7e2.css">
<script src="/assets/app.84b7e2.js" defer></script>

Most build tools do this automatically. For a hand-written site, change the filename whenever you publish a materially different asset.

How to check the real headers after deployment

Do not infer headers from files in your ZIP. Check the live URL. In a terminal:

curl -I https://your-site.ziphost.co/

# Check one asset too
curl -I https://your-site.ziphost.co/assets/app.84b7e2.js

Look for the HTTP status, content-type, HTTPS-related behavior, and any caching headers the platform returns. Browser DevTools also works: open Network, reload the page, select a request, then open Headers.

When you need a header the ZIP cannot provide

For API CORS: configure Access-Control-Allow-Origin on the API server. A static frontend cannot grant itself CORS access.
For strict CSP, HSTS, framing, or downloads: use a reverse proxy/CDN that supports response rules, or a hosting setup where server configuration is part of the product.
For redirects: use the domain or proxy layer. An HTML meta refresh is only a fallback and is not equivalent to an HTTP redirect.
For app-specific headers in PHP: deploy as a PHP site and send headers from your application, for example header("X-Content-Type-Options: nosniff"); before output.

Before you ZIP and upload

Put index.html at the root of the ZIP.
Use relative asset paths and open the extracted ZIP locally once.
Keep private files, API keys, .env files, and source maps you do not intend to publish out of the archive.
Deploy, open the live URL, and run curl -I before sharing it.
If a required header is missing, solve it at the platform, proxy, API, or application layer—not by adding a server config file to the ZIP.

The practical takeaway

ZipHost is a simple way to publish a static site from a ZIP. Your archive controls the page and its assets; the hosting layer controls HTTP response headers. Treat that boundary as a feature: it prevents uploaded files from changing shared server behavior. When you need precise response rules, use the right configuration layer and verify the live response instead of trusting a filename.