How to Deploy a Static Website to Cloudflare Pages, Netlify, and Vercel

Overview

If your project outputs HTML, CSS, JavaScript, images, and other static assets, all three platforms can host it well. The right choice usually comes down to workflow fit rather than raw capability. Before comparing buttons and dashboards, start with one question: what exactly are you deploying?

There are three common static-site cases:

• Plain static files: a folder with index.html, stylesheets, scripts, and assets.
• Static site generator output: a project built with tools such as Astro, Hugo, Eleventy, Vite, or similar, where deployment uses the generated output directory.
• Framework project with static export: a framework app that can emit a static build for hosting on a CDN-backed platform.

From there, your checklist is simple:

1. Confirm the build command, if any.
2. Identify the publish directory.
3. Connect the correct Git repository or prepare a manual upload.
4. Set environment variables only if the build process needs them.
5. Verify preview deployments for branches or pull requests.
6. Attach the custom domain.
7. Check caching, redirects, headers, and error pages.
8. Run a post-deploy test pass before announcing the site.

Cloudflare Pages, Netlify, and Vercel all support this general flow. The differences are usually in how opinionated they are about framework detection, how they present redirects and functions, and how tightly they connect build previews to Git workflows.

A good rule is to keep your deployment setup readable from the repository alone. If a teammate cannot tell the build command, output directory, and domain requirements by reading the repo and its config files, the setup will be harder to maintain. If you need a refresher on config formats used in build and deployment files, see JSON vs YAML vs TOML: Which Config Format to Use in Modern Projects.

Checklist by scenario

This section gives you a repeatable checklist based on the type of site you are shipping.

Scenario 1: Deploying plain static files

This is the simplest path and a good baseline for all three platforms.

• Prepare the folder: make sure the root contains an index.html entry point and that asset paths are correct.
• Use relative or correct absolute paths: broken image or stylesheet links often come from assuming the site will live at the domain root when it may be deployed under a preview path first.
• Choose a deploy method: either connect a Git repository or use drag-and-drop/manual upload if the platform supports it and your workflow allows it.
• Set the publish directory: for plain sites, this may be the repository root or a dedicated public folder.
• Test the preview URL: click through every page, not just the homepage.
• Add the custom domain: do this only after the preview is correct.
• Configure redirects if needed: especially if old URLs must continue working.

Best fit: all three are reasonable here. For very simple brochure sites, docs microsites, and landing pages, pick the platform that best matches your DNS, team habits, or existing account setup.

Scenario 2: Deploying a static site generator

For generators, the platform matters less than getting the build settings right.

• Run the build locally first: do not debug the hosting platform before confirming that npm run build or the equivalent works on your machine.
• Identify the output directory: common names include dist, build, public, or a tool-specific folder.
• Lock your runtime expectations: if the build uses Node.js or package-manager features, keep the project configuration explicit.
• Commit the source, not generated files: in most Git-based workflows, the platform should build the site from source unless you have a deliberate reason not to.
• Confirm framework detection: automated detection can help, but you should still verify the command and output path in the dashboard or config file.
• Review preview behavior: branch deploys are useful for content review, documentation changes, and design sign-off.

Best fit: all three support this pattern well. The deciding factor is often whether your team prefers the deployment experience, the DNS relationship, or nearby features like edge logic and forms.

Scenario 3: Deploying a framework as a fully static export

This is where teams sometimes blur the line between a static site and an app that expects server features.

• Confirm the app can export statically: not every route or feature in every framework works in a pure static deployment.
• Check routing behavior: client-side routing may require rewrite rules so deep links do not return 404 errors.
• Audit dynamic features: image optimization, server rendering, API routes, and auth callbacks may need alternate handling or should be disabled for a static target.
• Test refreshes on nested routes: open a deep URL directly in a new tab to confirm routing works outside the homepage.
• Set base paths carefully: especially if the app is deployed in a subdirectory during previews or staging.

Best fit: Vercel often feels natural for teams already using framework-heavy frontend workflows, while Netlify and Cloudflare Pages can work well when the final output is truly static. The important point is not the brand; it is whether the project remains static after build.

Scenario 4: Team workflow with Git previews and branch reviews

If multiple people review changes before release, preview deployments matter as much as production deploys.

• Connect the repository to the platform account used by the team, not a personal throwaway account.
• Define the production branch clearly.
• Use preview builds for every branch or pull request so changes can be reviewed without local setup.
• Keep secrets out of preview builds unless necessary.
• Document rollback steps: if a bad deploy reaches production, the team should know whether to redeploy a prior commit, revert in Git, or restore via the platform UI.

Best fit: Netlify and Vercel are commonly favored for polished preview workflows, while Cloudflare Pages also fits well for Git-driven static deployments, especially when paired with a Cloudflare-based domain and DNS setup.

Scenario 5: Fastest route for a personal site or portfolio

If your goal is speed rather than team process, use the platform that removes the most account friction.

• Choose one repository.
• Use one build command.
• Deploy one output directory.
• Attach one custom domain.
• Skip nonessential edge features until the site is live.

A common mistake is trying to solve future scaling questions before the first successful deploy. Static hosting is forgiving. Start with the smallest working setup, then add redirects, headers, analytics, or edge features later.

What to double-check

These are the deployment details that most often cause avoidable problems, regardless of platform.

1. Build command and publish directory

This is the first thing to verify. If the build command is wrong or the output directory points to source files instead of generated assets, the deployment may succeed but the site will be broken. Keep these settings documented in the repository README or deployment config.

2. Environment variables

Many static sites do not need runtime secrets, but the build step may still need environment values such as API base URLs, analytics keys, or feature flags. Double-check:

• which variables are required for production, preview, and local builds
• whether any secret is being exposed into client-side output by mistake
• whether preview builds should use a non-production endpoint

If your environment files or configuration become difficult to reason about, browser-based validation tools can help with structure and syntax. For related workflows, see Best Online JSON Formatter and Validator Tools for Developers.

3. Redirects and rewrites

Static sites often need one of these patterns:

• Old URL to new URL redirects after a site migration
• Single-page app rewrites so deep links resolve to the app shell
• Canonical host redirects such as non-www to www, or the reverse
• HTTP to HTTPS enforcement if not automatic

Do not assume default behavior matches your URL structure. Test several representative paths.

4. Custom domain and DNS

Domain setup is often where a quick deploy becomes a slow one. Before changing DNS, verify:

• who controls the registrar account
• whether the domain uses external DNS or the hosting provider's DNS
• which records need to be added, removed, or updated
• whether email records could be affected
• what the rollback plan is if the cutover goes wrong

Make DNS changes when you have time to test, not right before a launch announcement.

5. Caching behavior

Static hosting benefits from aggressive caching, but that only works cleanly if asset filenames are versioned or hashed during build. Double-check that your build process fingerprints JS and CSS bundles, and verify how the platform handles cache invalidation after a new deploy. If you need to understand hashing concepts used in asset pipelines, see Hash Generator Tools Online: MD5, SHA-256, and HMAC Options Compared.

6. Error pages and fallbacks

Create and test a usable 404 page. If the site has documentation, marketing pages, or a client-side router, a thoughtful 404 experience prevents confusion. Also test:

• a missing asset URL
• a mistyped content page URL
• a deep app route opened directly

7. Forms, APIs, and third-party integrations

A static frontend often depends on external services for forms, APIs, search, comments, or auth. Confirm that:

• the frontend points to the right endpoint in production
• CORS settings are correct
• callback URLs match the custom domain
• rate limits or bot protection do not block expected traffic

If your site accepts query parameters, redirects users based on URLs, or passes encoded values through forms, it is worth reviewing URL handling carefully with a reference like URL Encoder and Decoder Guide for Query Strings, Paths, and Form Data.

8. Content and documentation rendering

Many static sites include Markdown-based docs or blog content. Before launch, verify Markdown rendering, code fences, tables, and internal links in the deployed environment. For that workflow, Markdown Previewer Tools Compared for Docs, READMEs, and Static Sites is a useful companion.

Common mistakes

Most deployment issues are not caused by the platform. They come from assumptions made before deployment.

Treating a non-static app as if it were static

If the app depends on server rendering, server-side sessions, API routes, or framework-specific runtime features, a static host may not be the right target without adjustments. Decide early whether the project is truly static, partially dynamic, or server-driven.

Trusting auto-detection without verification

Automatic framework detection is helpful, but you should still inspect the build command, output directory, and environment variables. A successful deploy is not the same as a correct deploy.

Launching before testing the custom domain

The preview URL working is only half the job. Always verify the final domain, including HTTPS, redirect rules, asset loading, and any external auth or API callbacks.

Breaking deep links in single-page apps

If your router expects rewrites and they are missing, users will see 404 errors when opening shared links or refreshing nested routes. This is one of the most common static hosting mistakes.

Exposing secrets in client-side builds

Anything included in the built frontend should be treated as public unless your build system clearly keeps it server-side. Static sites do not have a hidden runtime environment in the same way traditional servers do.

Mixing deployment ownership

A site tied to one developer's personal account, domain login, or ad hoc DNS setup becomes harder to hand off. Use team-owned accounts and document access paths from the start.

Skipping a rollback plan

Even static sites need rollback discipline. Know how to redeploy a previous commit, revert DNS if necessary, and communicate the recovery path to the team.

When to revisit

This checklist is most useful when something changes. Revisit your setup before seasonal planning cycles, before redesigns, and whenever your workflow, framework, or hosting platform changes.

Here is a practical review routine you can use every few months:

1. Reconfirm build settings: make sure the repository still reflects the intended production command and output folder.
2. Review domains and DNS: check ownership, records, and whether any stale entries remain from previous migrations.
3. Test preview deployments: confirm branch builds still work and that reviewers know where to find them.
4. Audit redirects: remove obsolete rules and add any needed for recent content or URL changes.
5. Inspect integrations: verify APIs, forms, auth callbacks, and analytics after any vendor or domain update.
6. Review access and ownership: remove former contributors and ensure shared ownership is documented.
7. Check whether the project is still truly static: if the app now depends on dynamic features, reassess whether your current hosting model still fits.

If you are choosing between Cloudflare Pages, Netlify, and Vercel today, use this short decision rule:

• Choose the one that makes your current workflow simplest, not the one with the longest feature list.
• Favor explicit configuration over dashboard memory.
• Optimize for repeatable team deployment if more than one person will maintain the site.
• Keep domain and DNS planning close to deployment planning.

A final checklist before you click the production switch:

• The local build works.
• The publish directory is correct.
• Preview deployment is reviewed.
• Deep links and redirects are tested.
• Environment variables are intentional.
• Custom domain and HTTPS are verified.
• Rollback steps are documented.

That is the stable core of static deployment, regardless of which of the three platforms you choose. Interfaces will change. Product names may shift. But if you can answer those seven points clearly, you can deploy with confidence and revisit the setup later without starting from zero.