Github Pages
Assetlinks & AASA Generator
Generate Android assetlinks.json and Apple App Site Association (AASA) files for Universal Links and Android App Links.
Tools
Tools for custom domains, static publishing, launch checks, and GitHub Pages website maintenance.
Available tools
Github Pages
Generate Android assetlinks.json and Apple App Site Association (AASA) files for Universal Links and Android App Links.
Github Pages
Build correct Cache-Control HTTP headers for static assets, HTML pages, feeds, and sensitive content.
Github Pages
Build Cross-Origin isolation headers for SharedArrayBuffer, WebAssembly threads, and cross-origin security. Choose from presets with debugging checklists.
Github Pages
Generate CORS HTTP headers for any origin, method, and credential configuration. Output in raw HTTP, Nginx, Apache, Express, or Cloudflare Workers format.
Github Pages
Paste raw HTTP response headers and get a grouped, plain-English explanation of each header. Includes security advisories for missing security headers.
Github Pages
Create the CNAME file content and DNS notes for a GitHub Pages custom domain.
Github Pages
Convert a CSV redirect map to Netlify _redirects, netlify.toml, Vercel vercel.json, Apache .htaccess, or Nginx config. Validate duplicates and redirect chains.
Github Pages
Generate and validate security.txt files per RFC 9116. Specify your contact, expiration, and optional fields, then get hosting guidance for GitHub Pages, Netlify, and Vercel.
Github Pages
Generate a 404.html fallback for single-page apps on GitHub Pages.
Github Pages
Generate a VAPID key pair for Web Push notifications using the browser's Web Crypto API. Output ready-to-use keys for Node web-push, Firebase, and environment variables.
Github Pages
Enter a domain name and see example A, AAAA, CNAME, MX, and TXT records with setup notes.
Github Pages
Generate a GitHub Actions workflow YAML to deploy a static site, Vite, or Astro project to GitHub Pages.
Github Pages
Generate Report-To and Reporting-Endpoints HTTP headers for Nginx and Apache, plus CSP Reporting and Network Error Logging configuration.
Github Pages
Generate server configuration for Zstandard (zstd) compression with Content-Encoding headers, Accept-Encoding negotiation, and fallback chains for Nginx, Apache, Cloudflare, and Netlify.
GitHub Pages is simple once it is set up, but its domain and publishing rules are unforgiving. A CNAME file in the wrong folder, an outdated custom domain setting, or a missing build artifact can turn a correct website into a 404. These helpers focus on the checks that matter before and after deployment.
Use GitHub Pages tools when you set up a new site, move an existing site to a custom domain, or troubleshoot a deployment that is not serving correctly. Start by confirming your site repository settings: the publishing source branch and folder. Use the CNAME helper to prepare a custom domain file and verify your DNS configuration before enabling HTTPS. Add a 404 HTML page for single-page applications that handle client-side routing. Finish with the SEO checklist to verify that your generated output includes essential files like robots.txt, sitemap.xml, and proper metadata.
FAQ
The CNAME file must be part of your published output. If your build tool generates a dist folder and GitHub Pages serves from that folder, the CNAME file must be created or copied into dist during the build. A CNAME file outside the published folder is ignored and disappears on re-deploy.
For the apex domain such as example.com, GitHub Pages recommends ALIAS or ANAME records because apex domains cannot use standard CNAME records per DNS standards. The alternative is to redirect the apex to a www subdomain and use a CNAME record on the www subdomain.
Common causes include publishing from the wrong branch or folder, a missing index.html in the published root, delayed Pages deployment queue time, or a custom domain that does not resolve to the correct GitHub Pages IP address.
Yes, but the published site is public even if the repository is private. GitHub Pages serves site content publicly regardless of repository visibility.
If you host multiple sites from separate repositories under subdomains of the same apex domain, each repository needs its own CNAME file with the matching subdomain. One CNAME file cannot cover multiple subdomains.