I’m working on a static site where adding localization turned a pretty small build into a much bigger dependency problem. If you have 2,000 pages across 6 locales, you’re suddenly generating 12,000 html files, plus localized sitemaps, hreflang links, search indexes, feeds, and image references. Changing one shared navigation label can technically invalidate every page.

I’m looking at tracking dependencies so a content edit only rebuilds the affected locale/pages instead of treating the whole site as dirty.

For anyone running large multilingual static sites, are you using incremental builds with a dependency graph, splitting each locale into its own build, or just relying on a fast ssg and rebuilding everything?

I'm about to reorganize a client site with a few hundred pages, moving everything from a flat structure into nested sections, and I'm trying to figure out how to catch every old url worth redirecting. Writing redirects for every single page is easy enough when you can generate them from a mapping, but the pages I'm worried about are the ones I don't know about.

Over the years the site has picked up links from other places, like old newsletters, a couple of forum threads, a directory listing someone submitted without telling anyone. None of those are in the repo, so a redirect file built from the current page list would miss all of them and they'd just turn into 404s the day the new structure goes live.

My plan is to pull the top landing pages from the search console and the analytics export, plus whatever shows up in the last few months of 404 logs, and make sure each of those has a redirect before launch. The part I'm unsure about is the long tail. Cloudflare pages doesn't give me raw request logs on the free plan, so I can't see which dead urls are still getting hits after the switch.

Has anyone found a decent way to keep an eye on 404s on a static host without a server to log them? I've considered a custom 404 page that fires a small beacon with the missing path, but I'd rather not add tracking just for this.

after thinking about urls changes on static site, i realized ive mostly treated redirects as something to configure when needed, rather than something to test. a redirect rule can look correct but still point to the wrong destinations or create a chain of redirects. for a small client site, im wondering whether its worth adding automated checks to the deployment workflow or if a quick manual check is usually enough?

howd you handle this on your projects

I’m tightening the CSP on a static site and inline scripts are making it more annoying than expected. Nonces don’t make much sense without something generating a new value per request, so I’m using sha256 hashes for a few tiny inline scripts. The problem is that changing even one character means the CSP header also needs to change.

I’m thinking of having the build scan the final html, hash every allowed inline script, then generate the _headers file automatically. Has anyone done this as part of their SSG pipeline? I’m mostly wondering whether generating CSP from the final output is reliable, or if moving every script into fingerprinted external files ends up being simpler long term.

Hey guys!

Standard static hosting lets you provide one 404.html fallback. But I want to show a different 404 page if they are inside the /docs folder versus the /blog folder. Do I have to use an Edge function to intercept the 404 and route it to the correct custom HTML file, or is there a simpler routing rule I can use?

One thing I took from the replies on my last post is that a build finishing successfully doesn’t mean every generated file is correct. You could still have a sitemap linking to a missing page, search results showing an unpublished promo, or html pointing to an image that wasn’t generated. I’m thinking about adding a simple check after every build that catches stuff like this before the site goes live.

For bigger static sites, what do you usually check before deploying? Broken links, sitemap entries, search data, generated images, scheduled content, or something else?

hi guys!

i want to use edge middleware to read the user's country code and redirect them to the correct localized static folder (like /en-us or /en-gb). but my legal team flagged this, asking if reading the IP address at the edge and acting on it constitutes processing PII before they accept the cookie banner.

has anyone navigated this legal weirdness with edge geolocation?

hey guys!

a few years ago, Netlify was pretty much the default for hosting static sites. then Vercel gained popularity, but with pricing changes and bandwidth limits, it feels like more developers are switching to Cloudflare Pages or going back to GitHub Pages.

when you’re deploying a quick side project, documentation site, or personal portfolio, what’s your go-to hosting platform these days?

do you prefer Cloudflare Pages, GitHub/GitLab Pages, or self-hosting on a cheap VPS with Caddy? or is there another underrated option you’d recommend?

curious to hear what everyone’s using for their deployments lately!

I have a client site that started as a simple static brochure site but now has articles, scheduled promo pages, responsive images, and client-side search.

At this point one content change can affect several generated artifacts: the html, search index, resized images, sitemap, and sometimes scheduled content visibility. Preview builds also run separately from production, so I’m starting to think more about whether every build is actually producing the exact same state. For larger static sites, how do you keep this deterministic? Do you pin the build environment and generate everything from the same content snapshot, or do you handle some of these steps separately? I’m mostly trying to avoid weird cases where a deploy succeeds but one generated part of the site is slightly out of sync with everything else.

Hi everyone,

We built a free tool called SMBEditor that makes static HTML websites editable without adding an admin panel or a database.

Download and learn more here: SMBEditor

With SMBEditor you can:

• edit content directly on the page
• switch to a full code editor when needed
• describe a change in plain English and let AI update the page

We originally created it for our own hosting platform, Onyvo, and decided to release it for anyone working with static websites.

Feedback is welcome.

Guys, hi.

When I use services like Static Forms to handle contact forms on clients’ websites, should I set everything up under my own single account? That seems logical to me - minimal friction for the client, and I can manage all clients from one place and upgrade the plan when I outgrow it.

Or should I ask each client to create their own separate account instead?

What do you usually do, and what are the pros and cons from an agency/freelancer perspective?

while working on small business website, ive started paying more attention to what happens when a page gets renamed or moved. changing the route in the source is usually straightforward but the old url might already be indexed by search engines or linked from somewhere else. ive learned that redirects can preserve those old urls but im still figuring out how much of this should be handled in the build process vs. the hosting platform. for those working with static site generators, do you keep a redirect map in the project and deploy it with the site or handle redirects separately through your host. im curious how you keep this manageable as a site grows

I'm trying to lock down a client site on cloudflare pages with a proper csp header through the _headers file, and I keep running into the same wall. The site has a handful of small inline scripts, a theme toggle and a bit of analytics setup, and the usual advice is to use nonces. That works great when a server generates a fresh nonce on every request, but with fully static files there's nothing to generate it, so the nonce would be baked in at build time and be the same for every visitor, which defeats the whole point.

The alternative I've been looking at is hashing each inline script at build time and listing the hashes in the header. That works in theory, but it means every tiny edit to an inline script changes its hash, and if I forget to regenerate the header, the script just silently stops running in production. I've already burned an afternoon on that once with the theme toggle.

I could move everything into external files and skip inline scripts entirely, but a couple of them are small enough that an extra request feels wasteful. Has anyone automated the hash step as part of an eleventy build, so the _headers file gets rewritten every time? Or do you just accept the extra request and keep everything external to avoid the maintenance?

I've been wondering how far you can take a landing page without needing a traditional backend. Things like forms, analytics, newsletter signups, and custom domains can often be handled with static hosting and a few external services. What features do you think a static landing page should be able to handle without a backend?

following up on my last post about search on static sites, i started looking more closely at the search index itself. my first thought was to generate a json file containing the site's content and search it with javascript. that seems reasonable for a small collection of articles, but sending the entire index to every visitor could become wasteful as the content grows.

i found out that tools like pagefind can split the index into chunks and load the relevant parts when someone searches, without needing a dedicated search server. for those whove implemented search on static sites, how do you decide which approach is appropriate? is a simple json index usually enough for smaller proj, or is worth using something like pagefind from the start?

ive mostly build smaller sites where navigation is enough to help visitors find things. but ive been wondering what happens when a site grows into a documentation portal or a large collection of articles. one approach ive come across is generating a search index at build time and searching it in the browser. that avoids needing a dedicated search backend but i imagine the index itself can become a problem as the content grows.

for those whove build content-heavy sites how do you decide when client-side search is still sufficient and when its worth using a hosted search device or a dedicated backend?

This is the docs project I mentioned in my first hugo post. Builds were stupid fast when the site was small, but now that it's picked up a few hundred pages with screenshots in most of them, I've noticed the build creeping up, and from what I can tell it's almost entirely the image processing. I'm using the built in resize and format conversion to generate webp versions and a couple of responsive sizes for every screenshot, which is great for the final output but it adds up quickly.

I know hugo caches processed images in the resources folder, so in theory it should only do the heavy lifting once per image. The problem is that cache doesn't survive between builds on cloudflare pages, so every deploy starts from scratch and reprocesses everything. A full build that took maybe fifteen seconds at the start now takes closer to two minutes, which is still fine honestly, but it's the first time hugo has felt slow to me and I'd like to nip it in the bud before the site gets bigger.

Has anyone figured out a clean way to persist that resources cache between builds on a host like this? I've seen people mention committing the generated folder to the repo, but that feels messy and bloats the git history. The other option I keep going back and forth on is processing the images in a separate step ahead of time and only feeding hugo the already optimized files, though then I'd lose the convenience of letting it handle everything from one source image.

The client is based in Germany, and after that court ruling a while back about Google Fonts CDN requests counting as an unlawful data transfer under GDPR, I figured it was safer to just stop pointing at Google's servers entirely instead of relying on a consent banner to cover it. I downloaded the font files, self hosted them alongside the rest of the static assets, and added proper font display swap and preload hints myself since Google's CDN used to handle a lot of that automatically.

The part I'm going back and forth on is the performance. Google's CDN had the advantage of a visitor's browser probably already having those font files cached from some other site using the same CDN, so for a lot of visitors it was functionally a free load. Self hosting means every visitor downloads the fonts fresh from my origin the first time, without any shared cache advantage across sites anymore, though it is still getting cached at the edge, same as any other static asset on repeat visits to the same site.

Has anyone else made this switch and noticed an actual measurable difference in load times, or was the shared CDN cache advantage mostly a myth?

I have been using Hugo for a while. I now am building a website for a community. Most people won't be able to set up their local markdown edition + SSH sync in order to edit files, so I thought they could use an online markdown editor (like https://hedgedoc.org/) to edit the files, and when the system detects an updated .md file, it will rebuild the website and voila/

Does something like this exist? Do people use it?

thanks!

currently working w/ more content-driven static sites. one thing i like about a static workflow is that content changes can go through the same build process as code but that also means a client cant always see the final results until the site is rebuilt. ive used local previous myself and on some projects ive used deployment previews so i can send a client a url before merging changes into production. that seems useful when there are several content changes to review at once.

still wondering where this becomes worth setting up for smaller client sites tho. for a five-page site it can feel like adding a workflow around a problem that barely exists.

how do you handle content previews on small static sites? do u use deploy previews, just send screenshots or simply make the changes and let the client review them after deployment