How to Host a Website on Cloudflare

Quick answer: For a conventional static site or a framework that builds to static files, start with Cloudflare Pages. Connect a Git repository or upload the build output; Pages deploys it to a *.pages.dev address and can create pull-request previews. Choose Workers Static Assets when the project needs Worker code, server-side behavior, bindings, or a Wrangler-first workflow. For a business-critical production site, attach a custom domain or route rather than relying on workers.dev.

This guide walks through both deployment paths, domain setup, framework output, troubleshooting, and operational choices. Cloudflare describes Workers as its primary application platform and says it supports most Pages use cases with a broader feature set; Pages remains a straightforward way to publish Git-built static sites and previews. See the official Pages documentation and Workers Static Assets documentation.

1. Choose Pages or Workers

Need	Good starting point	Why
Static HTML, a static site generator, or framework output with no server runtime	Pages	Git integration or Direct Upload, a pages.dev hostname, and preview deployments.
Worker code, server-side behavior, or bindings alongside assets	Workers Static Assets	Deploy assets and Worker behavior as one Wrangler-managed project.
Framework app with server-side rendering	Workers, using the framework’s Cloudflare-supported setup	Static export alone cannot run request-time server code.
Git-connected deploys and pull-request previews are the main need	Pages	Pages integrates repository builds and preview deployments.

Cloudflare marks Workers Sites as deprecated in Wrangler v4 and recommends Workers Static Assets for new full-stack projects. Do not start a new deployment with Workers Sites; use the current Static Assets path.

Cloudflare’s documentation describes workers.dev as intended for personal or hobby projects that are not business-critical. Use a custom domain or Worker route for a production endpoint. Pages projects also have a production branch and preview deployments, which can be useful when reviewing changes before publishing.

2. Prepare the website files

Plain HTML

Put a top-level index.html in the directory you plan to deploy. For example:

site/
├── index.html
├── styles.css
└── images/
    └── banner.webp

Use relative asset paths that match the published directory. If the browser requests /styles.css, that file needs to be present at the output root.

Framework build

Identify two values before configuring Pages: the command that builds the site and the directory containing the finished deployable files. The output directory is not necessarily your source directory. Build locally if useful and inspect the output: it should contain index.html at its top level for a conventional site root.

Cloudflare’s static HTML example allows an optional build command such as exit 0 when there is no build step, with a configured output directory. For a Next.js static export, Cloudflare documents npx next build and out as the build directory. Static export is appropriate only when the site can be served as generated files; features requiring a running server need a compatible Workers deployment. Check the current Next.js Pages guide and your framework’s deployment requirements.

3. Deploy with Cloudflare Pages

1. Open Workers & Pages in the Cloudflare dashboard and choose to create an application, then choose Pages.
2. Select a Git repository for automatic builds, or select Direct Upload to publish already-built files. Cloudflare also offers C3 for creating supported projects.
3. For Git, choose the production branch and enter the build command and output directory for the project. For plain HTML with no build step, use the static HTML configuration described in the Pages guide.
4. Deploy and open the generated *.pages.dev hostname. Check the root page and any assets or routes the site needs.
5. For Git-connected projects, push a small change to confirm that the intended branch builds. Pull requests can receive preview deployments; review the preview before merging.

Pages rebuilds when commits arrive on the configured production branch. Keep generated files, environment configuration, and branch expectations clear: a successful build from the wrong branch or output directory can still publish the wrong site.

4. Deploy with Workers Static Assets

Use this route when static files are part of a Worker project or you want Wrangler to manage development and deployment. Create a Worker project using Cloudflare’s current setup guidance, place site assets in the configured public directory, and configure the project’s Wrangler settings for the assets and any Worker code or bindings it uses.

# Install and configure Wrangler through the project setup instructions.
# Run the Worker locally:
npx wrangler dev

# Publish the configured Worker and its assets:
npx wrangler deploy

These commands assume Wrangler is installed or available through the project and that the project configuration is in place. Follow the current Static Assets guide for the required configuration fields; do not copy a configuration from an older Workers Sites tutorial. Local development with wrangler dev lets you check Worker behavior and asset paths before publishing.

After deployment, Cloudflare can expose the Worker on a workers.dev subdomain or through a configured custom domain or route. For production, associate the production hostname as described below.

5. Register or connect a domain

If you do not own a domain yet, register one with a registrar before starting custom-domain setup. Choose a name you control and keep access to the registrar account: domain renewal and DNS changes depend on it. Cloudflare is also a domain registrar, but check the current availability and registration terms for the name you want.

Pages custom domain

1. Open the Pages project and go to Custom domains. Add the hostname there first.
2. For an apex domain such as example.com, the domain must be a Cloudflare zone with its nameservers pointed to Cloudflare.
3. For a subdomain such as www.example.com, configure a CNAME to <YOUR_SITE>.pages.dev. Associate the custom domain in the Pages dashboard before relying on the DNS record.
4. Wait for DNS and certificate provisioning, then test both the custom hostname and the Pages hostname.

Adding only a DNS CNAME without completing the Pages custom-domain association can result in a 522. Follow the Pages dashboard flow so Cloudflare knows which project should serve the hostname. See Pages custom domains.

Workers custom domain or route

For a Worker, open its settings and add a Custom Domain under Domains & Routes, or configure a route for the hostname. Cloudflare creates the DNS record and certificate for a custom domain. Use a custom domain when the Worker should own that hostname; use a route when the Worker should handle matching traffic on a zone according to the route configuration. Review the current Workers routing documentation before changing an existing site’s routing.

Check existing CAA records if certificate issuance stalls. A restrictive CAA policy can prevent Cloudflare’s accepted certificate authority from issuing a certificate; adjust the zone’s policy to allow an accepted authority.

6. Check the deployment before calling it done

• Open the site’s root URL and confirm the expected page loads.
• Check stylesheet, script, and image requests in the browser’s network panel for missing paths.
• Test internal links, refresh a nested route, and confirm the framework’s routing behavior.
• For a dynamic site, exercise the Worker code and bindings, not only the static landing page.
• Open the custom domain over HTTPS after DNS and certificate setup completes.
• For Pages, check a preview deployment before merging a change to the production branch.

For a web screenshot of the published page, a browser automation script can capture it directly. That is useful for a one-off check, but it requires browser setup and does not by itself remove consent banners or overlays.

7. Troubleshooting common Cloudflare hosting errors

Symptom	Likely cause	Fix
Pages root returns 404	The deployed output does not contain a top-level index.html, or the output directory points to the wrong folder.	Inspect the build artifact, correct the output directory, and deploy again.
Pages custom domain returns 522	A DNS record was created before the hostname was associated with the Pages project.	Add the hostname under the project’s Custom domains, then confirm the CNAME points to the correct pages.dev hostname.
Certificate does not issue	CAA records may exclude the certificate authority Cloudflare needs.	Review the zone’s CAA policy and allow an accepted authority, then allow provisioning to complete.
Styles or images are missing	Paths are absolute or relative to a different directory than the deployed output, or files were omitted from the artifact.	Check the requested URL and make the file path and output layout agree.
Worker deploy fails or assets return errors	Project configuration, asset directory, or bindings do not match the current Static Assets format.	Compare the project with the current Workers Static Assets guide; avoid deprecated Workers Sites configuration.
Static Next.js deployment lacks a page feature	The feature needs request-time server rendering, but the deployment is only a static export.	Confirm the framework feature supports static export or choose a Cloudflare Workers deployment that supports the app’s server behavior.
Changes do not appear	The wrong branch was deployed, a build has not completed, or the browser is showing a cached response.	Check the deployment’s branch and build status, then reload the deployed URL and inspect the response and asset URLs.

8. Performance, reliability, and cost choices

Keep the build output lean: include only files the site serves, optimize large images before deployment, and avoid unnecessary client-side JavaScript. For a static site, choose Pages when its Git build and preview workflow is enough. For dynamic behavior, include only the Worker logic and bindings the application needs, and test them locally and on a preview or non-production endpoint before routing production traffic.

Use Pages previews and production rollbacks as part of the release workflow. Verify the build output and the actual custom domain after changes that affect routing, certificates, or environment configuration. No traffic, performance, uptime, or price figures are asserted here; consult Cloudflare’s current product and plan documentation for account-specific limits and charges. The product choice should follow runtime needs and deployment workflow rather than an assumed benchmark.

9. Capture a clean screenshot of the deployed site

For a manual screenshot, use a browser capture tool after the site is available and check the page at the viewport and state you care about. A screenshot may include cookie consent banners, newsletter popups, or chat widgets. If you need repeatable captures across URLs, options such as full-page capture, waits, and viewport size matter.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns an image or PDF; its clean-shot flow accepts consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before capture, with each step configurable. Only clean shots are billed: bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -o shot.webp

1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000. The same API also supports Python and Node.js:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));

Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed; an MCP server lets AI agents take screenshots; and 1,000 screenshots a month are free with no card, with paid plans starting at $5 for 3,000. Sign up free for ScreenshotNeo.

10. Frequently asked questions

Can Cloudflare host a website without Git?

Yes. Pages supports Direct Upload for prepared output files. Git integration is useful when you want automatic builds from repository changes.

Do I need a custom domain to publish?

No. Pages provides a pages.dev hostname, and Workers can use workers.dev. Configure a custom domain when you need your own hostname; use a custom domain or route for a production Worker endpoint.

Can I deploy a Next.js site to Pages?

A statically exported Next.js site can use the documented Pages build command and out output directory. If the application needs server-side features, use a supported Workers deployment path instead of treating it as static files.

Should I use Workers Sites for a new site?

No. Cloudflare marks Workers Sites deprecated in Wrangler v4 and recommends Workers Static Assets for full-stack applications.