How to Deploy a Static Website: GitHub Pages, Netlify, and Cloudflare Pages Compared

Overview

If your site is made of HTML, CSS, JavaScript, or files generated by a static site generator, you can usually host it without a traditional web server. In practical terms, that means you push your code to a Git repository, connect that repository to a hosting platform, and let the platform publish the output for you.

The three platforms in this tutorial solve the same core problem in slightly different ways:

• GitHub Pages is often the most direct choice when your code already lives on GitHub and your needs are simple.
• Netlify is often the easiest choice when you want a polished deployment workflow, deploy previews, and straightforward handling of forms, redirects, or build settings.
• Cloudflare Pages is often a strong fit when you want static hosting tied closely to Cloudflare DNS, edge delivery, and a cleaner path to broader Cloudflare tooling.

Rather than asking which platform is universally best, ask a narrower question: Which one matches the way I build and update this site? That framing stays useful even as dashboards and defaults change.

Before you begin, make sure you have:

• A Git repository with your site files
• A clear publish directory if you use a build tool
• A domain name if you plan to use a custom URL
• Access to your DNS provider
• A short prelaunch checklist for links, assets, and metadata

If your Git workflow still feels inconsistent, it helps to review a basic command routine before deployment. The Git Cheat Sheet for Everyday Commands: Clone, Branch, Commit, Merge, and Undo is a useful companion for that step.

A simple way to choose

Use this quick filter before you touch any settings:

• Choose GitHub Pages if you want the simplest path for a portfolio, documentation site, project page, or small brochure site with minimal platform-specific features.
• Choose Netlify if you want a beginner friendly tutorial style workflow with preview deployments, branch-based testing, and more built-in deployment controls.
• Choose Cloudflare Pages if your DNS is already on Cloudflare or you expect to use Cloudflare services beyond static hosting.

All three can host a static site well. The main differences usually come down to deployment behavior, custom domain setup, and how much control you want over previews and edge features.

Checklist by scenario

This section is the reusable part: pick the scenario that matches your project and follow the checklist in order.

Scenario 1: You have plain HTML, CSS, and JavaScript with no build step

This is the easiest type of static website deployment guide to follow because there is no separate output folder and no framework-specific build command.

Best default choice: GitHub Pages

1. Create or confirm a GitHub repository for the site.
2. Place your homepage at index.html in the expected publishing location.
3. Push the repository to GitHub.
4. Open the repository settings and find the Pages section.
5. Select the branch and folder to publish.
6. Save the settings and wait for the first deployment.
7. Open the generated site URL and verify that assets load correctly.

Use this option when: you want simple hosting with minimal setup and you do not need advanced previews or deployment logic.

Watch for: relative paths, missing index.html, and confusion between a user site and a project site path structure.

Alternative: Netlify or Cloudflare Pages

If you want drag-and-drop style ease or future flexibility, both platforms can publish a folder or a repository with almost no build configuration. You typically connect the repository, skip a build command if none is required, define the publish directory if needed, and deploy.

Scenario 2: You use a static site generator or frontend framework

If your site is built from source files into an output directory such as dist, build, or public, your platform choice matters more because build settings must be correct.

Best default choice: Netlify or Cloudflare Pages

1. Identify the build command used locally.
2. Identify the publish directory created after the build finishes.
3. Push your project to GitHub.
4. Connect the repository to Netlify or Cloudflare Pages.
5. Enter the build command exactly as used in your project.
6. Set the publish directory to the generated output folder, not the source folder.
7. Run the first deployment and review build logs for warnings or failed dependencies.
8. Open the deployed URL and test internal routes, images, and JavaScript bundles.

Use this option when: you need a practical tutorial workflow with repeatable builds and clearer deployment visibility.

Watch for: environment variables, wrong output directory, and framework settings that assume a root path different from your deployed URL.

Scenario 3: You need preview deployments before merging changes

If your team wants to review changes on a live preview URL before they reach production, GitHub Pages is usually not the first platform to consider.

Best default choice: Netlify or Cloudflare Pages

1. Connect the repository to the platform.
2. Confirm the production branch.
3. Use feature branches or pull requests for changes.
4. Check that the platform creates a preview deployment for branch changes.
5. Review the preview URL on desktop and mobile.
6. Merge only after content, styling, and links are approved.

Use this option when: your project has more than one contributor or content changes need a review step.

Watch for: previews that work on temporary URLs but break after production because environment variables, redirects, or domain assumptions differ.

Scenario 4: You already use Cloudflare DNS

If your domain is managed in Cloudflare, Cloudflare Pages can reduce friction because DNS and hosting are managed closer together.

Best default choice: Cloudflare Pages

1. Connect your repository to Cloudflare Pages.
2. Set the build command and output directory if required.
3. Deploy the site to the generated Pages URL first.
4. Add your custom domain inside the Pages project.
5. Review DNS records created or requested by the platform.
6. Wait for DNS propagation and certificate issuance.
7. Test the custom domain over HTTPS.

Use this option when: you want simpler domain and SSL setup inside the same ecosystem.

Watch for: overlapping DNS records, proxy behavior you did not intend, and stale browser DNS cache if the site does not appear immediately. If your domain fails to resolve, see How to Fix DNS_PROBE_FINISHED_NXDOMAIN: Domain and Browser Troubleshooting Steps.

Scenario 5: You need a custom domain on any platform

This is where many static deployments slow down. The hosting itself is often easy; the domain and SSL setup needs more care.

1. Deploy the site to the platform-provided temporary URL first.
2. Confirm the site works before changing DNS.
3. Add the custom domain inside the hosting platform.
4. Copy only the DNS records the platform asks for.
5. Remove conflicting old records if they point elsewhere.
6. Wait for DNS propagation.
7. Confirm the domain loads over both the root domain and www if you intend to support both.
8. Set your preferred canonical version and redirect the other.

Use this option when: you want a production-ready domain instead of a platform subdomain.

Watch for: partial DNS changes, certificate delay, and mixed content warnings after HTTPS is enabled. If assets still load over HTTP, review How to Fix Mixed Content Errors After Enabling HTTPS.

Scenario 6: You want the simplest possible decision

• Choose GitHub Pages for a lightweight project site with basic deployment needs.
• Choose Netlify for an easy setup guide style experience with richer deployment workflow.
• Choose Cloudflare Pages if Cloudflare already manages your domain or you want tighter DNS integration.

What to double-check

Once the first deployment succeeds, do not assume the job is finished. A static website can appear to work while still containing routing, caching, or domain issues that surface later.

1. The publish directory is correct

This is one of the most common problems. If your site generator outputs to dist but the platform publishes the project root, you may see a default page, a partial build, or a failed deployment. Confirm the platform is serving the final generated files, not your source files.

2. Asset paths match the final URL structure

Check whether your CSS, images, and JavaScript use absolute or relative paths. A site deployed at a subpath can break if it assumes root-level paths. This matters especially for project pages and documentation sites.

3. Redirects and rewrites are intentional

Single-page apps often need a fallback route so direct navigation to internal paths does not return a 404. Static sites with old URLs may also need redirects. Review this before launch, especially if you are replacing an older site structure. If you are deciding between section structures, Subdomain vs Subdirectory for SEO and Site Structure: When to Use Each can help you plan URLs before deployment.

4. HTTPS works on the final domain

Open the real production URL and test it in a fresh browser session. Do not rely only on the platform preview URL. Verify that the certificate is active and that no scripts, fonts, or images still request HTTP resources.

5. DNS records are clean

It is easy to leave behind old A, CNAME, or redirect records from a previous host. That can cause inconsistent results depending on cache and resolver location. Keep only the records your current setup actually needs.

6. Caching is not hiding problems

If you change DNS or redeploy a file and still see the old version, test with a private browser window, another device, or a cache bypass. Static hosting is fast partly because content is cached aggressively, which means stale results can mislead you during troubleshooting.

7. Basic production checks pass

• Homepage loads
• Main navigation works
• Internal links do not 404
• Images render
• CSS and JavaScript files load without console errors
• Metadata and title tags are present
• Custom domain resolves correctly
• HTTPS is active

If you are comparing this with more traditional hosting choices for larger projects, it helps to read How to Choose Web Hosting for a Small Website: Shared, VPS, Cloud, and Managed Options so you can tell when static hosting is enough and when it is not.

Common mistakes

Most static deployment issues are not deep technical failures. They are small mismatches between repository structure, build settings, and DNS records.

Publishing source files instead of built files

A framework project may look complete in the repository but still require a build step before it becomes a usable static site. Always confirm what the platform is serving.

Testing only the platform subdomain

The temporary deployment URL can work perfectly while the custom domain remains misconfigured. Always test the final domain, with HTTPS, after DNS changes finish propagating.

Forgetting a fallback route for single-page apps

If your app relies on client-side routing, visiting an internal URL directly can return a 404 unless you set the necessary rewrite or fallback behavior.

Using inconsistent canonical domains

Decide whether the root domain or www version is primary. Then redirect the secondary version. Inconsistent domain handling can create duplicate URLs and confusing analytics.

Changing too many things at once

Deploy the site to the platform URL first. Then add the custom domain. Then configure redirects or advanced rules. Sequencing the work makes troubleshooting far easier.

Assuming static hosting behaves like a traditional server

On many static hosts, server-side code, dynamic database logic, and certain rewrite behaviors do not work the same way as they would on shared or VPS hosting. Make sure the project is truly static or that any dynamic functionality uses platform-supported alternatives.

Not keeping a rollback habit

Even simple sites benefit from a clean Git history and branch workflow. If a deployment breaks, you want a quick path back to the last known good version.

When to revisit

This topic is worth revisiting whenever your workflow changes, not just when a site breaks. A platform that fits a one-page portfolio may stop fitting once the project adds a team, a custom build process, or stricter review requirements.

Review your setup again in these cases:

• You move to a new framework or static site generator
• You add a custom domain or change DNS providers
• You need preview deployments for team review
• You add redirects, rewrites, or client-side routing
• You notice mixed content, 404s, or inconsistent HTTPS behavior
• You migrate from a small project to a production site with more contributors
• Your seasonal planning cycle includes infrastructure cleanup or documentation updates

A practical deployment checklist to save

1. Confirm whether the site is plain static files or a build-based project.
2. Choose the platform based on workflow, not just familiarity.
3. Deploy to the platform URL first.
4. Verify the correct output folder is being published.
5. Test links, routes, images, and scripts.
6. Add the custom domain only after the test deployment works.
7. Update DNS carefully and remove conflicting records.
8. Confirm HTTPS and canonical domain behavior.
9. Document the build command, publish directory, and DNS records for future updates.
10. Revisit the setup before major redesigns, domain changes, or team workflow changes.

If your next step involves a more complex site lifecycle, you may also want to review related operational guides such as How to Create a Staging Site for WordPress and Test Changes Safely or How to Migrate a WordPress Site to a New Host Without Downtime. They cover a different stack, but the underlying lesson is similar: separate testing from production, change one layer at a time, and verify the final domain rather than assuming the deployment is complete.

The short version is simple. GitHub Pages is usually enough for a straightforward static site, Netlify is often the easiest all-around workflow choice, and Cloudflare Pages is often the smoothest fit when Cloudflare already sits at the center of your DNS and delivery setup. Use that as a starting point, then let your actual deployment process make the final decision.