Hugo Static Site on Cloudflare | Hacker News Reader

Hugo Static Site on Cloudflare

techlife.blog

10 pointstsenturk19 comments

I don't see anything of substance on this post. There is no explanation on how it was done.

Yeah, was kind of hoping for some tiling it GitHub links etc.

Aside, deploying to GitHub pages is definitely neat and fast AF of your site is hot/active... Otherwise first load can take a few seconds.

The title alone is indicative of a future without exorbitantly expensive Vercel and Netlify.

Vercel and Netlify charge 10,000x for a pretty UI and not much else. Their closed source nature even makes automation harder.

I'm hopeful we'll have a stack to give us the same experience and deploy to any provider soon.

Meh... One more Chat GPT post in the internet that happens to hit HN first page.

This article wasn’t written by ChatGPT — I wrote it myself. It’s meant to be just a brief explanation. I’m currently preparing a detailed piece about Workers & Pages, but it’s not that easy. The documentation isn’t very clear, so you end up figuring out many things empirically.

In an announcement[0] earlier this year, Cloudflare essentially put Cloudflare Pages on life support and began advising potential CFP users to build sites on the newly enhanced Cloudflare Workers platform instead.

I later wrote about this, particularly as it related to Hugo users.[1][2]

[0]: https://blog.cloudflare.com/full-stack-development-on-cloudf...

[1]: https://www.brycewray.com/posts/2025/05/pages-workers-again/

[2]: https://www.brycewray.com/posts/2025/07/hugo-sites-cloudflar...

This is a bit of a misunderstanding.

We are not sunsetting Pages. We are taking all the Pages-specific features and turning them into general Workers features -- which we should have done in the first place. At some point -- when we can do it with zero chance of breakage -- we will auto-migrate all Pages projects to this new implementation, essentially merging the platforms. We're not ready to auto-migrate yet, but if you're willing to do a little work you can manually migrate most Pages projects to Workers today. If you'd rather not, that's fine, you can keep using Pages and wait for the auto-migration later.

Thank you for the clarification, sir. I wish that they had run that original Cloudflare blog post by you, especially this particular paragraph:

> Now that Workers supports both serving static assets and server-side rendering, you should *start with Workers*. Cloudflare Pages will continue to be supported, but, going forward, all of our investment, optimizations, and feature work will be dedicated to improving Workers. We aim to make Workers the best platform for building full-stack apps, building upon your feedback of what went well with Pages and what we could improve.

... which sounds (at least to me) more like an “either/or” situation, and a “Pages-is-going-into-maintenance mode” situation, than your answer suggests. But perhaps that’s just how I took it.

You aren't the only one who was confused! We bungled the messaging there.

And when they move to workers we lose access to generic pages urls? Everything I generate going forward has my username in it? It would be nice to leave the first come first serve anonymous urls as an option.

I have a site generator that won’t run on workers. Can I just use a storage bucket in Pages and be sure it will survive that migration?

My mom was paying a few hundred a year to Wix for a basic single page, static site. I finally decided that it was a waste of money and went down the Hugo-on-cloudflare route a few months ago. Can't beat it - all she's paying for now is the domain.

The only issue I had encountered was moving the domain from wix. If memory serves me right, I had to point the NS records to CF to do the transfer, and Wix doesn't allow control over them. I ended up transferring over to Porkbun instead, but using CF for DNS.

Hugo took some getting used to. Most of the templates I had seen were for blogs, but "hugo-scroll" works like a charm for the basic single page site.

I've found cloudflare pages to be overwhelming to work with. There are two seeming flavours of it and the differences aren't explained well or easy to find, and many parts of the documentation being outright incorrect. An explanation regarding how this was done would have been great in this post.

You’re absolutely right. There are two different ways to build: 1.Workers 2.Pages And they can be quite confusing. I’ve started writing a new article to explain the differences in detail.

> But in our world where speed is important for SEO,

I agree site speed is very important, but I don't buy into the SEO argument. Some of the most popular sites in the world take ages to load.

Speed is considered one of many ranking factors. I think less because Google explicitly says "we will rank you higher if your site is faster" and more "the user behaviors we track will improve if your site is faster".

This is things like going from the SERP -> Site -> Back to the SERP.

That's implicitly telling Google that the site didn't satisfy their search intent and something they for sure track.

Maybe the user clicked back b/c the page didn't load fast enough, maybe the content was bad but either way it's a search quality signal.

There's also a fixed amount of time google's crawler will spend indexing your site; the faster your pages load, the more of them will get indexed.

That being said, if you return results too quickly then Google will hit your site more frequently. In our case, it's been frequently enough such that we'll give Googlegot a 429 response. Interestingly enough, the Google Search Console does not acknowledge 429s, but misreports them as 500s.

Search engines want to rank the most popular sites in the world. They won't rank ones that are slow and not high volume.

Reply on news.ycombinator.com