Paying twenty bucks a month on Vercel or Netlify for bandwidth overages on a static marketing page is just lighting cash on fire. You don’t need a heavy Node runtime or a serverless setup for flat assets. You need cheap storage for your origin, solid DNS, and a CDN sitting in front to deliver sub-50ms response times worldwide.
When you get hit with a traffic spike from an ad run or Product Hunt, you want plain HTML, CSS, JavaScript, and WebP files served straight out of edge memory—not hitting your origin server and triggering rate limits.
The Architecture: Hostinger Origin, Namecheap DNS, and the CDN
Here’s how requests travel. Namecheap resolves the DNS query via an ALIAS or CNAME record pointed at your CDN distribution. The edge PoP inspects its cache. If the asset is hot, it serves it right there with an x-cache: HIT header. On a cache miss, the CDN pulls the file from Hostinger over HTTPS, stores a copy based on your origin headers, and hands it to the visitor.
Hostinger handles storage, fallback SSL, and server-side rewrite rules under LiteSpeed. Namecheap takes care of zone records. The CDN absorbs 95% of your bandwidth and deflects bot garbage. I mapped out a similar pattern in my guide on deploying a web app on Hostinger with Namecheap DNS and StackPath CDN, but a static site is even easier to maintain since you don’t have a database to worry about.
Prepare and Optimize Your Static Build
Before touching your server, run your build locally and double-check the output directory. Whether you’re running Astro, Vite, Hugo, or raw HTML, your deployment folder needs an index.html right at its root alongside the assets.
Kick off your build step locally:
# For standard Vite or Astro setups
npm run build # Inspect the output directory
ls -la dist/Make sure your bundler produces hashed filenames like main.8f2a1b.css or vendor.d43b2c.js. Cache busting with content hashes is non-negotiable here. It lets you tell edge nodes to cache files for a year without ever having to click a manual “purge cache” button when you push an update.
Provision Hostinger and Push Assets via SSH or Rsync
Log in to Hostinger hPanel and add your domain under Websites. That scaffolds the folder structure at /home/u123456789/domains/yourdomain.com/public_html/.
Enable SSH inside hPanel under Advanced > SSH Access. Grab your port, server IP, and username. Skip the clunky web file manager—sync your built dist folder directly from your terminal using rsync:
rsync -avz -e "ssh -p 65002" ./dist/ u123456789@195.35.12.84:/home/u123456789/domains/yourdomain.com/public_html/The -avz flags preserve permissions, copy directories recursively, and compress files over the wire. If you’ve moved sites around before, this is the exact same workflow I walked through in our guide on migrating to Hostinger via SSH and rsync.
Configure .htaccess for Caching and Security Headers
Hostinger runs LiteSpeed Web Server, which parses standard Apache .htaccess files. Create an .htaccess inside public_html/ to dictate your caching headers before edge proxies ever touch the origin.
Here’s the configuration I use to lock down security and establish solid cache rules:
# Cache HTML for 10 minutes with background revalidation Header set Cache-Control "public, max-age=600, stale-while-revalidate=3600" # Cache static hashed assets for 1 year Header set Cache-Control "public, max-age=31536000, immutable" # Prevent iframe embedding and MIME sniffing Header always set X-Frame-Options "SAMEORIGIN" Header always set X-Content-Type-Options "nosniff" Header always set Referrer-Policy "strict-origin-when-cross-origin"
# Route clean URLs for single-page applications
RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.html [L]
That immutable flag tells browsers and edge nodes that the file will never change, cutting out unnecessary revalidation requests entirely. Check the MDN Cache-Control documentation if you want to tweak how stale-while-revalidate serves background refreshes during deployments.
Configure Namecheap DNS Records
Head to Namecheap, open your Domain List, and hit Manage next to your domain. Under Nameservers, make sure you’re using Namecheap BasicDNS or WebDNS so the Advanced DNS tab stays editable.
Because traffic routes through the CDN, your root domain and subdomains should point directly to the CDN edge, not Hostinger’s origin IP. Set up your records like this:
# Namecheap Host Records table
Type Host Value TTL
ALIAS Record @ edge.yourcdndistribution.net. Automatic
CNAME Record www edge.yourcdndistribution.net. Automatic
TXT Record _origin 195.35.12.84 AutomaticIf your CDN uses Anycast A records (like Cloudflare or StackPath edge IPs) instead of CNAME/ALIAS flattening on the root, enter their designated IP addresses instead. Check propagation directly from your terminal to make sure Namecheap published the records:
dig +short yourdomain.com
dig +short www.yourdomain.com CNAMEIf you’re running custom nameservers or trickier routing, my walkthrough on connecting Namecheap DNS to CDN with a Hostinger origin goes deeper into edge routing quirks.
Set Up the CDN Edge Cache and Origin Mapping
In your CDN dashboard, create a new site or distribution. Put Hostinger’s shared server IP or default hostname in as your Origin Address.
Lock in these origin settings:
- Origin Protocol: HTTPS (Port 443).
- Origin Host Header: Set this explicitly to
yourdomain.com. Hostinger’s vhost router needs this to match the request to yourpublic_html/directory instead of throwing a generic default page. - SNI (Server Name Indication): Enabled.
- SSL Verification: Strict or Full.
Configure an Edge Rule to obey origin Cache-Control headers. That keeps your static bundles cached for up to a year while revalidating index.html every 10 minutes. Also, configure the edge to strip cookie headers on static files. Take a look at how to strip Set-Cookie headers for static assets on CDN so you don’t fragment your edge cache across different visitors.
The Gotcha I Hit: Font CORS Errors and Edge Compression
The first time I deployed this setup, everything loaded fine except my custom typography. The whole page dropped back to Times New Roman. Popping open DevTools showed every single .woff2 request failing with a Cross-Origin Request Blocked (CORS) error.
Because the CDN serves your static assets from an edge hostname or subdomain, modern browsers block font files unless the response includes an explicit Access-Control-Allow-Origin header. Hostinger’s default LiteSpeed setup doesn’t append this header to fonts out of the box.
You can fix it by adding this snippet to your .htaccess file inside public_html/:
Header set Access-Control-Allow-Origin "*" Header append Vary "Origin"
If you’re using an Nginx stack rather than Hostinger’s LiteSpeed setup, check out our guide on how to fix CORS font loading errors on CDN with Nginx for the matching add_header directive.
What I Ran: Verifying Cache Status with cURL
Once your DNS updates and the CDN connects to Hostinger, run curl against an asset to verify cache behavior, compression, and response headers:
curl -I -H "Accept-Encoding: gzip, br" https://yourdomain.com/assets/main.8f2a1b.cssLook through the output for proper edge caching headers:
HTTP/2 200
date: Mon, 14 Apr 2025 10:14:22 GMT
content-type: text/css; charset=utf-8
cache-control: public, max-age=31536000, immutable
vary: Accept-Encoding
x-cache: HIT
content-encoding: br
server: LiteSpeedRun that command twice. The first hit might return x-cache: MISS while the edge fetches the bundle from Hostinger. The second run should return HIT, shaving TTFB from ~280ms down to around 25ms. You can cross-check your live metrics against Core Web Vitals thresholds on web.dev.
Frequently Asked Questions
Do I need a paid Hostinger tier for static websites?
No. Even the entry-level Single or Premium Shared hosting plans handle this fine. The CDN absorbs practically all your traffic, so Hostinger only ever sees cold cache misses and deployment syncs.
How do I update the landing page without breaking the cache?
Rely on hashed filenames for your CSS and JS bundles (like bundle.a1c3e.js). When you deploy, the new HTML points to the new filenames. Since your HTML has a short 10-minute cache with stale-while-revalidate, visitors get fresh code almost immediately without needing a manual edge cache purge.
Why does my site throw an infinite redirect loop when CDN SSL is on?
This happens when the CDN talks to Hostinger over plain HTTP (Port 80) while Hostinger has “Force HTTPS” turned on. Hostinger sends a 301 back to the CDN, which forwards it to the browser, creating an infinite loop. Fix it by setting the CDN origin protocol to strict HTTPS (Port 443) and issuing a free Let’s Encrypt cert in hPanel.
Can I deploy automated updates through GitHub Actions?
Yes. Add your Hostinger SSH private key to your GitHub repository secrets, then add a deploy step that runs the same rsync command right after npm run build.
Next Steps
Now that your static landing page is cached at the edge and insulated from origin traffic spikes, you can restrict origin access so requests only come through verified CDN IPs. Take a look at our guide on configuring Nginx Cache-Control immutable headers to squeeze every bit of performance out of your asset delivery.
