Is my pages.dev subdomain automatically reachable even after I add a custom domain?

Yes. Adding a custom domain to a Cloudflare Pages project doesn't disable its original *.pages.dev subdomain, both continue serving the same deployment unless you explicitly redirect or restrict the pages.dev one.

Does Google actually index pages.dev URLs in practice?

It can, especially if the pages.dev URL gets linked to externally (shared in a chat, referenced in an old README, or crawled before you added a custom domain). Once indexed, it competes with your production URL for the same search queries until you apply a fix like a canonical tag or a redirect.

Which single fix matters most if I can only do one?

The forced redirect from the pages.dev domain to production (`https://project.pages.dev/* https://example.com/:splat 301!`) is the most complete single fix, it stops both crawlers and human visitors from ever seeing the duplicate at all, rather than just hinting to search engines which version to prefer.

What's the difference between this tool and the Staging Domain Blocker?

This tool is a diagnostic report explaining the risks and listing the fixes in context. The Staging Domain Blocker directly generates the ready-to-deploy robots.txt/_headers/_redirects file contents for fix #2 and #3. Use this one to understand and communicate the risk, and the other to get the deployable files.

pages.dev Duplicate Content Risk Checker

Overview

Introduction

Every Cloudflare Pages project gets a free *.pages.dev subdomain, and it keeps working even after you attach a custom production domain, which quietly creates two live copies of your entire site.

This tool turns your production domain and Pages project name into a concrete risk report, plus the exact fixes, instead of leaving you to piece together whether this actually matters for your project.

What Is pages.dev Duplicate Content Checker?

A duplicate-content risk checker: enter your production domain and Cloudflare Pages project name, and it derives the matching pages.dev subdomain and explains the specific SEO risks of both being reachable.

It ends with the concrete fixes (a canonical tag, a forced redirect rule, and a noindex/robots.txt setup) written out with your actual domain values filled in.

How pages.dev Duplicate Content Checker Works

Your Pages project name becomes `{project-name}.pages.dev` (Cloudflare's fixed subdomain pattern), and both domains are normalized (protocol and trailing slash stripped) before being used in the report.

The report lists the general risks of the situation, then a numbered fix list with real, copy-pasteable snippets: a canonical `<link>` tag, a forced `_redirects` rule, and a reminder to add robots.txt/X-Robots-Tag protection on the pages.dev domain.

When To Use pages.dev Duplicate Content Checker

Use it right after connecting a custom domain to a new Cloudflare Pages project, to confirm you've closed the duplicate-content gap before it becomes a real problem.

It's also useful when auditing an older project you didn't set up yourself, to quickly check whether this common oversight applies.

Often used alongside Cloudflare Staging Domain Blocker, Cloudflare Pages robots.txt Generator and Cloudflare Pages _redirects File Generator.

Features

Advantages

Fills in your actual domain and project name into every snippet, so the fixes are ready to use, not generic placeholders.
Explains the risk in plain terms, useful for justifying the work to a teammate or stakeholder who asks "why does this matter?"
Points directly at the Staging Domain Blocker tool for the deployable file contents, so the next step is obvious.

Limitations

Doesn't check whether your pages.dev URL is actually indexed right now, it's a risk/fix report based on how Cloudflare Pages works generally, not a live search-index lookup.
Assumes the standard *.pages.dev subdomain pattern; a project using a different Pages deployment alias would need manual adjustment.

Examples

Checking a project named "my-project" with production domain example.com

Input

production domain: example.com, pages.dev project name: my-project

Output

Production domain:  https://example.com
pages.dev domain:   https://my-project.pages.dev

Risks:
  - Both https://example.com and https://my-project.pages.dev can serve identical content...

Fixes to apply:
  1. Add a canonical tag to every page pointing at production:
     <link rel="canonical" href="https://example.com/" />
  2. Force-redirect the pages.dev domain to production via _redirects:
     https://my-project.pages.dev/*  https://example.com/:splat  301!

The report derives the pages.dev domain from the project name and fills both domains into every risk and fix line.

Best Practices & Notes

Best Practices

Apply the forced redirect (fix #2) as the primary defense, it's the only fix that also protects against non-search-engine traffic (shared links, bookmarks) ending up on the wrong domain.
Add the canonical tag even if you also redirect, it's a cheap extra signal and protects you if the redirect is ever accidentally removed.
Check this immediately after any domain migration, not just initial setup, since old pages.dev links tend to resurface after a rename.

Developer Notes

The pages.dev domain is derived purely by string concatenation (`${projectName}.pages.dev`) since that's Cloudflare Pages' fixed, non-configurable subdomain pattern; both the production domain and project name inputs are validated and normalized (lowercase, no protocol/trailing slash) before being interpolated into the report's snippets.

pages.dev Duplicate Content Checker Use Cases

Verifying a new Cloudflare Pages project's custom domain setup doesn't leave a duplicate-content gap
Auditing an existing project you inherited for this specific, easy-to-miss SEO risk
Explaining to a teammate why the pages.dev URL needs to redirect rather than just be ignored

Common Mistakes

Assuming that adding a custom domain automatically disables or hides the original pages.dev subdomain, it doesn't.
Relying on a canonical tag alone without also redirecting or noindexing the pages.dev domain, leaving it fully crawlable and linkable.

Tips

Run the Cloudflare Staging Domain Blocker tool right after this one, it generates the exact deployable files for fixes #2 and #3.

pages.dev Duplicate Content Checker