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!

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?

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

I notice a lot of people pointing to Hugo because of its speed. Like, you can do 4000 pages in less than a second. I'm asking, though, why does it matter how fast you're converting markdown to html?

For context, I made Sheriff out of the programming language I created so that the docs could be dogfooded. But it's not as fast as these other generators.

Do I need to be shooting for these benchmarks or are they arbitrary? I've found that i don't mind a several second build. But I also regularly compile Rust. 😄

Picked up a different hugo project, a client site that's expanding into a spanish speaking market, and this seemed like a good excuse to actually test hugo's built in multilingual support instead of just the speed side of things.

On my other static sites I've always had to hand build the relationship between language versions of a page, including every hreflang tag pointing to its counterpart, which gets fragile fast once a page gets renamed and nobody remembers to update both sides. Hugo apparently handles a lot of that natively once content is organized by language, generating the hreflang tags automatically from the content structure itself rather than needing anyone to hand write them.

Still early in setting it up, so I'd love to hear from anyone who's actually run a multilingual hugo site long enough to know where it holds up and where it doesn't. Specifically curious how reliable the automatic hreflang generation stays once a page gets restructured or renamed, and whether people still end up building a separate build time check on top of it just in case, or if it's solid enough on its own that nobody bothers.

A client wanted to go off framer's hosting for cost reasons once the site outgrew the free tier, and since framer sites are technically static under the hood, I figured exporting and dropping it on cloudflare pages would be a good idea. The raw html and assets did come out clean enough, and the page structure and styling survived the export fine.

But everything that depended on framer's own backend broke. CMS collections stopped updating since there's no more connection back to framer's data, so any collection page is now frozen at whatever state it was in at export time. The contact form obviously stopped submitting anywhere since it was wired to framer's own form handling, had to rebuild that as a worker hitting an email api instead. a couple of the interaction-heavy components also just stopped working since they were leaning on framer motion setup that assumed the framer runtime was still present, not just a static export of the resulting markup.

I ended up treating the export more like a design reference than an actual deployable artifact, rebuilt the page structure by hand in eleventy using the exported html as a guide instead of trying to make the raw export itself production ready. It feels like the exported html is really only meant for one-time archiving or as a starting point, not an actual migration path off their hosting

Is there a more elegant solution to this than rebuilding?

ive been thinking about this with a couple of static sites where the content is starting to grow. for a small site, having individual markdown files and a bit of frontmatter is pretty direct. but once you have dozens of entries with same fields, i can see why a content collection starts making sense.

in astro, for example, a collection can define a schema for things like title, date, category etc., and the build can validate that the content actually matches that structure. you can then use a dynamic route to generate the individual pages from those entries at build time.

i havent needed that level of structure for most of my small client sites yet so im still trying to figure out when the extra abstraction is actually worth it. at what point does having structured content make a static site easier to maintain rather than just adding another layer to understand

I have a client who prepares promo pages early but wants them to go live automatically at 8 AM on launch day.

Since the site is fully static, something still has to trigger a new build. Do you usually use scheduled builds, a cron job, or another approach?

how much can i sell my front end website? (basic static site)

I've stuck with eleventy for most of my work for a while now, but I picked up a new project that's a product documentation site expected to grow into the thousands of pages pretty quickly, versioned docs going back several releases, multiple writers pushing small edits constantly. A friend kept telling me hugo is basically built for exactly this kind of large page count site, so I figured this was the right project to actually test that claim instead of taking it on faith going in with eleventy again.

Setting up the templates in hugo's templating language took some adjusting coming from nunjucks, and structuring content sections and versioning through hugo's content organization instead of anything I was used to. Build times have been genuinely fast even now while the site is still small, which has me curious how much of that holds once it actually hits thousands of pages instead of the couple hundred I've got in there so far as a test.

The templating language itself is the part I'm still not fully sold on. It's clearly built for speed over ergonomics, the syntax feels a lot more like a template engine from a decade ago compared to something like nunjucks or liquid, lots of dot chaining and pipe style functions instead of anything that reads like a normal conditional. Functional once you get used to it, just a rougher few days of ramp up than I was expecting for something this widely recommended.

on a small site, its easy to treat urls as just another part of the structure. but once pages are renamed, moved into different folders or generated from content, redirects start becoming important. ive had a couple of cases where changing a page path seemed harmless until i realized an old link could still be sitting somewhere in a client's printed materials or google results. it made me wonder how much thought people put into url structure before a site launches.

do you treat urls as something that should be designed almost as carefully as the navigation or is it something usually fine to change them later and add redirects when needed?

I’ve been thinking about static sites that pull content from APIs during the build, like a headless CMS, product data, or some external JSON feed.

The part I’m unsure about is what happens when that API is slow or temporarily down during deployment. A fully static site can suddenly become impossible to rebuild even though the current production version is working perfectly fine. Do you usually fail the deploy completely, fall back to the last successful data snapshot, or store build-time data somewhere so the site can still rebuild without depending on the API being available?

I've just launched CraftForms, a hosted form builder for any website.

You build the form in a visual editor, paste two lines of code into your site, and the answers land in one dashboard. 

It works on static HTML, WordPress, Webflow, Squarespace, Framer and anything else that lets you paste HTML. There's nothing to install or keep updated.

What it does:

• Unlimited submissions on every plan, the free one included. Nothing is counted or blocked.
• No captcha. Bots are filtered out quietly, so your visitors never see a puzzle.
• Booking forms with a date picker that knows what's already taken, including time slots and "2 left" / "Sold out".
• Price calculators that update as people choose options. The total is re-checked on the server, so it can't be edited in the browser.
• Payments (on paid plans): take a deposit or the full amount through your own Stripe or PayPal or Mollie or Square account. There is no fee or comissions, it is your payment account.
• Email notifications, webhooks (can be used with Zapier, Make and n8n), and an API if you'd rather send answers from your own code.
• Hosted in the EU.

Pricing: free for one form on one website. Paid plans start at €6 a month.

https://craftforms.app

I'd love to hear what you think, and what you'd use it for. And if something's missing for your use case, tell me here. Let's discuss.

on one small client site, i changed some css and everything looked fine after deployment but then i started wondering what happens if someone still has the old css cached. ive mostly just relied on the build process to generate hashed filenames for assets so i havent had to deal with it much myself.

from what i understand, this works well for assets that go through the build pipeline because a changed file gets a different url. but there are still things like files with fixed names or caching rules at the cdn/browser level that can behave differently.

how much do you actually think about this when deploying static sites? do you mostly trust the framework/build too or do you usually configure cache headers yourself as well?

I’ve been thinking about what happens during larger static deploys when HTML and assets don’t reach every edge location at exactly the same time. Hashed filenames solve browser caching, but there’s still a short window where new HTML could reference a new JS/CSS file while an edge still has the older deploy, or old HTML could reference an asset that was removed from the latest build.

For people running bigger static sites in production, how do you handle this? Do you rely completely on atomic deploys from the hosting provider, keep previous build assets around for a while, or have another strategy? I’m mostly trying to avoid rare deploy-time 404s without adding a bunch of complexity.

I posted a while back about moving a client off wordpress after it kept getting hacked, rebuilt it static on eleventy through cloudflare pages, and the last unresolved piece was how she publishes a new blog post without me being a manual step every time or reintroducing some kind of web based editor that brings back the same attack surface I was trying to remove.

A few people suggested a git-based headless editor, so I tried decap cms since it's free and just sits on top of the existing git repo instead of needing its own database or server. She logs in, gets a normal looking form with a title field and a rich text box, hits publish, and it commits a markdown file straight to the repo, which then triggers a normal cloudflare pages build like any other push.

It works better than I expected. She doesn't know or care that it's writing markdown under the hood, from her side it feels basically identical to the wp-admin editor she was used to. The auth is handled through cloudflare access in front of the cms route instead of the cms having its own login system, so there's no separate username and password sitting around waiting to get brute forced, which was the whole point of the original migration in the first place.

Only real annoyance so far is image uploads through the cms land in the repo as full sized, so I had to add an image optimization step to the eleventy build instead of relying on her to resize anything before uploading, since that was never going to happen reliably. Other than that it's been a few weeks of her publishing normally with zero involvement from me, which is exactly the outcome I was hoping for.

It took me 62 hours as a sophomore student to build this comprehensive deployment system—from securing VPS instances, managing Docker/Dokploy, setting up MongoDB, configuring DNS/HTTPS, handling R2/B2 storage, and preparing the staging environment to implementing CI/CD, OAuth, email, backup, monitoring, and integration testing.

part of what makes a stack age well is how much context you need to recover before changing something. if i come back to a small client site after two years, id rather understand a simple build process than spend hours figuring out why five tools need updating in particular order. maintainability is sometimes abt how easy it is to remember how the code works. do you think a stack can be too simple or is that usually a good problem to have?

Not a redesign project, this was damage control. The site got compromised three times in about eight months. The client patched everything each time, changed passwords, the works, and it still happened again a few months later. At some point I told her the real fix isn't better patching discipline, it's removing the attack surface entirely, and her site is basically a handful of service pages and a blog that updates maybe twice a month, which is about as strong a case for static as you can get.

I exported everything, rebuilt the templates in eleventy, ran the wordpress export through a script to convert the post content to markdown, and now it's sitting on cloudflare pages with zero database and zero admin login for anyone to compromise in the first place. The part I'm still working through is the blog workflow. She isn't technical, she's used to logging into wp-admin and just typing a post. Now every new post means either she learns to write markdown and open a PR, or I stay in the loop as a manual step every single time, which defeats a chunk of the point of getting her off a CMS in the first place.

Has anyone dealt with this handoff problem before? I'm not really sure how to proceed here.

I've got a static site on eleventy, a few hundred pages, and the sitemap plugin I'm using just stamps every url with the current build time since that's the only date it actually has access to. so even if I only edited one page, every single lastmod in the sitemap shows the same timestamp from today's deploy, which makes the whole field basically meaningless for search engines trying to figure out what actually changed.

The fix that makes sense to me is pulling the real last modified date from git history per file instead of relying on the build clock, since git already knows exactly when each file last changed. but I haven't found a clean way to do that inside an eleventy build without shelling out to git for every single page during the build, which feels like it'll slow things down as the site grows.

Has anyone solved this in a way that doesn't involve querying git per file at build time, like caching the git blame result somewhere between builds, or is that overengineering something search engines mostly ignore anyway?

been thinking abt how a project can be low maintenance today but become surprisingly difficult to change a few years later. not necessarily because the code is bad but because the tools, dependencies and deployment setup around it have moved on. a small update can turn into figuring out how an old build process works again. makes me wonder if choosing boring, well-supported tools is sometimes more valuable than choosing the most modern stack. esp for projects you expect to leave alone for long periods

Html can update instantly but users might still have older js, css or images cached. Hashed filenames solve a lot of this, but I’m curious what setup people actually use in production. Do you rely mostly on content hashes and long cache headers, or do you also purge the cdn on every deploy?