When I ship a small static site (Astro, plain HTML, 11ty, whatever), the build is the easy part. The stuff that makes it look finished and keeps it compliant is what I always forget. Here's the checklist I now run through — all of it free, all client-side or static, no backend required.
1. A favicon (don't skip this)
A site with no favicon looks unfinished in the tab and in bookmarks. You need a few sizes:
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="512x512" href="/icon-512.png">
You can generate all three from an image or just a letter in the browser with a free favicon generator — it spits out the PNGs and the exact tags above.
2. Compress your images BEFORE you commit them
Unoptimized images are the #1 cause of slow static sites. A 3 MB hero PNG has no business being 3 MB. Resize to the max width you actually render and re-encode to JPG/WebP at ~80% quality — usually a 70–90% size cut with no visible difference. I do it client-side (canvas + toBlob) so nothing gets uploaded: image compressor.
3. The legal pages (the part everyone forgets)
The moment you add analytics, a newsletter form, or sell anything, you need:
- a privacy policy (GDPR/CCPA + your analytics/email tools all require it),
- terms & conditions,
- a refund policy if you sell,
- and a cookie consent notice if you set cookies.
You can draft all of them from templates in a few minutes (then adapt to your real practices): free legal-pages generators. Publish each at /privacy, /terms, /refunds and link them in your footer.
Not legal advice — templates are a starting point, not a substitute for a lawyer on high-stakes stuff.
4. Technical SEO basics
-
sitemap.xml+robots.txt(Astro's sitemap integration is one line). - Unique
<title>+ meta description per page. - Open Graph tags so links unfurl nicely.
- Submit the sitemap in Google Search Console, and ping IndexNow on deploy so new pages get crawled fast.
5. A QR code for the printed/offline world
If the site backs a product, menu, or business card, generate a QR code that encodes the URL directly (not via a redirect that can expire), and export SVG for print.
That's the whole list. None of it needs a server or a paid plan — it's all static files and browser-side tools. What's on your pre-launch checklist that I missed?
(I build these free tools at CreatorLaunch — no signup, nothing uploaded.)
Top comments (1)
A no-backend static-site checklist is genuinely useful because most people massively over-build for what's actually a static site - you don't need a server, a database, or a deploy pipeline to ship a landing page or a portfolio, and the checklist format saves people from cargo-culting a backend they'll never use. Matching the architecture to the actual need (static when static suffices) is underrated discipline.
The interesting line is where "static" quietly stops being enough - the moment you need a contact form that actually delivers, gated content, or anything user-specific, you've crossed into needing a backend, and that transition catches people off guard. Knowing where that boundary is (and that crossing it is a real jump in complexity) is the useful adjacent skill. That's the gap I work on with Moonshift (a multi-agent pipeline that ships a prompt to a deployed SaaS) - when you DO cross into needing auth/data/backend, it handles that jump so you don't hand-wire it, ~$3 a build. Great practical checklist. Where do you tell people the line is - what's the first feature that forces them off pure-static into needing a backend? That threshold trips up a lot of beginners.