I am the person that tends to make mistakes a lot and recently, I helped get a blog out for a colleague on the Firebase Blog. In doing so, I used a temporary slug for the address and had no idea how to change it to the one the team actually wanted to use for the published post. Here is a cool trick I learned that helped me get the right redirects setup for the company blog.

Firebase Blog background

Our Firebase Blog is our way of communicating important Firebase information to our customers. The site is statically generated using Astro and then deployed to Firebase Hosting as an action. We have some actions that are manually invoked for deploying to production and some automated actions that help deploy to preview channels. My colleague Jeff generally is the go to person for the blog and has a lot of final say about what happens.

The problem

We had an event come up very recently that required a late night push on a Sunday night and I had a placeholder URL as the slug for the blog article. I pushed the blog and everything looked great on it, the problem was the product manager had selected a very specific slug that he had given to partners as an early share URL that wasn’t available. The other problem was that the product manager had already posted a link to the existing blog article and it was receiving lots of traffic already. I needed to fix the existing URL to be the one that our partners had and not break the existing URL in the process.

The fix

For Firebase Hosting, we have a way to configure redirects using the firebase.json file. That controls hosting configs. I have never tried updating redirects and it is relatively straightforward.

{
  "hosting": {
    "public": "dist",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    "cleanUrls": true,
    "trailingSlash": false,
    "redirects": [
      {
        "source": "/posts/2026/03/example-url-holder",
        "destination": "/posts/2026/03/the-real-url",
        "type": 301
      }
    ]
}

We merely add a redirects array to the firebase.json hosting property that includes an object containing a source and destination. This means that when users visit the source url, in this case /posts/2026/03/example-url-holder users will be automatically redirected to /posts/2026/03/the-real-url. I used a 301 as the redirect status code so the user’s browser will never try the old url again and instead go straight to the new URL.

Conclusion

There are still a lot of nice features that I never knew existed within Firebase and am often pleasantly surprised about them. As someone that has moved to more web development since joining Google, I always wondered how I would solve this with Firebase and because of the forcing function of the blog article, I now have my answer!

This is all about Firebase Hosting, which is meant for static sites. For SSR sites, I think Firebase App Hosting has its own way of handling that. I wonder what Jeff thinks?