AI AI Tools Guidebook
Indie Dev & Website Building

Firebase Hosting go-live checklist (10 items)

A 10-item pre-launch checklist for sites going live on Firebase Hosting in 2026 — covering domain, SSL, cache, redirects, sitemap, Search Console, and rollback rehearsal.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

You are about to point your real domain at Firebase Hosting. The site works in dev, it works on *.web.app. Before you flip DNS, run this 10-item checklist — every item is something an indie dev has been bitten by at least once.

Background

Most “first day live” disasters are avoidable. The fixes are five-minute things you do not think of until the day they bite you: a missing trailing-slash rule, an unsubmitted sitemap, a forgotten cache header. This list keeps you from spending launch day in firefighter mode.

Step by step

  1. Confirm firebase.json matches your actual build folder. For Astro that is dist, Next static export is out, Vite is dist. The full config you should ship to production for a static content site:
{
  "hosting": {
    "site": "your-firebase-project",
    "public": "dist",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
    "cleanUrls": true,
    "trailingSlash": true,
    "redirects": [
      { "source": "/blog/:slug", "destination": "/articles/:slug", "type": 301 }
    ],
    "headers": [
      {
        "source": "/_astro/**",
        "headers": [
          { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
        ]
      },
      {
        "source": "**/*.html",
        "headers": [
          { "key": "Cache-Control", "value": "public, max-age=300, s-maxage=3600" }
        ]
      },
      {
        "source": "**",
        "headers": [
          { "key": "X-Content-Type-Options", "value": "nosniff" },
          { "key": "Referrer-Policy",        "value": "strict-origin-when-cross-origin" }
        ]
      }
    ]
  }
}
  1. Decide canonical: apex or www. Add both domains in Firebase Console → Hosting → Add custom domain, then set the non-canonical one to redirect. Typical DNS records when going apex-primary:
Type   Name        Value
A      @           199.36.158.100
A      @           199.36.158.101
CNAME  www         your-project.web.app
  1. Confirm SSL on both hostnames before flipping traffic:
curl -vI https://yourdomain.com 2>&1 | grep -E 'subject:|issuer:|HTTP'
# subject: CN=yourdomain.com
# issuer: C=US, O=Google Trust Services LLC, CN=...
# HTTP/2 200

If you see subject: CN=*.web.app, the custom-domain cert has not been issued yet — wait, don’t flip DNS.

  1. Test trailing-slash and clean-URL rules in incognito for several path shapes:
curl -sI https://yourdomain.com/about    | head -1   # expect 301 or 200
curl -sI https://yourdomain.com/about/   | head -1   # expect 200
curl -sI https://yourdomain.com/missing/ | head -1   # expect 404, NOT 200
  1. Run Lighthouse on the live URL. Aim for Performance and Best Practices > 90:
npx lighthouse https://yourdomain.com/ \
  --only-categories=performance,best-practices,seo \
  --chrome-flags="--headless" --quiet
  1. Submit the sitemap to Search Console under the primary domain only — never the *.web.app URL or both apex+www:
Search Console → Sitemaps → Add a new sitemap
URL: https://yourdomain.com/sitemap-index.xml
  1. Set canonical and og:url to the production domain. Quick scan in your build output:
grep -ROIE 'rel="canonical"|og:url' dist | grep -v yourdomain.com | head
# any output = wrong domain leaked into the HTML
  1. Rehearse a rollback before you need one. Firebase keeps the last ~10 releases:
firebase hosting:releases:list
# release-1 (current)  2026-05-22 14:02  abc123
# release-0            2026-05-22 13:40  def456

# Practice rolling forward to a known-bad commit and back
firebase deploy --only hosting    # creates a new release
# Console: Hosting → Release history → ... → Rollback

  1. Set budget alerts. In GCP Console → Billing → Budgets & alerts, alerts at 50% and 90% of expected spend. For pure static hosting this should rarely fire.

  2. Final pre-flip checks, executed against the *.web.app URL before you switch DNS:

curl -s https://your-project.web.app/sitemap-index.xml | grep -c '<loc>'
curl -s https://your-project.web.app/robots.txt | head
curl -sI https://your-project.web.app/         | grep -i cache-control

If those three look right, you are clear to point DNS.

Common pitfalls

  • Skipping the canonical decision and ending up with both apex and www indexed in Google.
  • Submitting the sitemap on a non-canonical domain — wasted crawl budget.
  • Forgetting to update social meta (og:url) when switching to a new domain.
  • Going live on a Friday without a tested rollback.
  • Leaving the *.web.app URL in any sitemap or canonical tag.

Who this is for

Every indie dev doing a real launch on Firebase Hosting in 2026.

When to skip this

If you are still on a preview channel and not pointing a real domain yet, only steps 1-5 apply.

FAQ

  • How long before traffic stabilizes after switching DNS?: Most of the world is on the new host within 5-30 minutes if you lowered TTL beforehand. Full propagation can take up to 24 hours.
  • Should I disable the *.web.app URL after launch? — You cannot disable it, but you should set canonical tags and og:url to the custom domain so search and social do not pick up *.web.app.
  • Do I need a robots.txt?: Yes. Even a permissive one with just a sitemap reference helps crawlers find your sitemap fast.
  • What if I find a critical bug right after going live?: Hosting > Release history > Rollback to the previous release. Then fix and redeploy. Total downtime is usually under a minute.

Tags: #Indie dev #Firebase #Hosting #Workflow #SEO

Related Articles