Headers

Right, let’s talk about caching. Or more specifically, let’s talk about stopping your users from wanting to throw their laptops out a window because your website’s logo took three minutes to load on a fresh visit. It’s 2024. We’re better than that. The magic wand for this particular problem is the Cache-Control header, and for static assets—your CSS, JavaScript, images, fonts—it’s non-negotiable. This isn’t a polite suggestion; it’s the foundation of a performant site.

Right, let’s talk about the digital equivalent of a bouncer, a moat, and a “do not cross” police line all rolled into one: security headers. These are the unsung heroes of web security, the silent instructions you give a user’s browser to prevent it from doing stupid, dangerous things on your behalf. Ignore them, and you’re essentially leaving your front door wide open with a sign that says “All my sensitive user data is in the fridge.”

Right, the 404 page. The digital equivalent of a “You Had One Job” meme. Your user has asked for something, your server has looked everywhere, and the only thing it can muster is a terse, default error message that screams “amateur hour.” We’re not having that. We’re going to build a page that says, “Okay, we messed up, but we’re so good at messing up that we’re going to make it a delightful experience for you.”

Alright, let’s talk about the _redirects file. This is one of those beautifully simple yet deceptively powerful tools Cloudflare Pages gives you. Forget wrestling with a convoluted config file or writing a Lambda function just to send someone from point A to point B. This is your old-school, text-file-having, no-nonsense solution. The concept is dead simple: you create a file named _redirects (yes, with the underscore) in the root of your project’s build output. Inside, you write lines with three pieces: a source path, a destination, and a status code. It follows the same format Netlify uses, because why reinvent a perfectly good wheel?

Alright, let’s talk about getting people from point A to point B on your site, because sometimes you move things, and sometimes the internet just gets lost. We’re diving into Netlify’s two main tools for this: the classic _redirects file and the newer, shinier netlify.toml configuration. They both get the job done, but they have different vibes, like a trusty old wrench versus a multi-tool with a laser level. First, a crucial piece of wisdom: Netlify handles redirects after your site’s build process. This is different from a framework-level redirect. Your React or Gatsby router might handle a /about-us route, but if that route doesn’t exist in the final built HTML/CSS/JS, the request still hits Netlify’s servers. That’s when Netlify’s redirect engine—powered by either of these methods—kicks in. This is a huge strength; it means you can redirect any incoming path, even ones that never existed in your source code.

Now, let’s talk about Hugo’s aliases, which is a fancy way of saying “built-in redirect generation that saves you from a world of hurt.” You’ve been there: you move a page, and suddenly a perfectly good link is now a digital ghost town, leaving your users with a 404 error and a profound sense of abandonment. We’re better than that. Hugo, being the thoughtful static site generator it is, gives us the aliases front matter key to handle this elegantly.