To move a Cloudflare Pages site from *.pages.dev to a custom domain without losing Google, make every old URL answer a permanent 301 to the same path on the new domain, but keep your Search Console verification file reachable on the old host. Then point canonicals, hreflang and the sitemap at the new domain, verify both hosts in Search Console under one Google account, and file a Change of Address from the old property. Leave the redirect in place for at least a year.

Cloudflare's own guide covers the redirect rule. It doesn't cover the Search Console steps that decide whether rankings move with you. This page puts both in one checklist. Boloop moved from boloop.pages.dev to getboloop.com on 8 November 2026, and the observations below come from checking that move from the outside. It's too early to report ranking results, so this guide doesn't claim any.

Who this is for

  • You run a site on Cloudflare Pages and Google already shows some *.pages.dev URLs.
  • You've added, or are about to add, a custom domain, and you want those URLs and their signals to move to it.
  • You don't need this if the pages.dev site was never indexed. In that case a 301 or a noindex is enough, and Search Console steps are optional.

Which redirect should pages.dev use?

Use a server-side permanent redirect (301 or 308) that keeps the path and query string. Cloudflare's documented method is a Bulk Redirect: a list entry with source <project>.pages.dev, target https://example.com, status 301 and the options Preserve query string, Subpath matching and Preserve path suffix, plus a Bulk Redirect rule that uses the list.

Two details trip people up:

  • A `_redirects` line won't do it. Cloudflare's redirects documentation lists domain-level redirects as unsupported in _redirects, and says _redirects isn't applied to responses served by Pages Functions. People report the same thing in practice: a https://project.pages.dev/* https://project.com/:splat 301 line "never fires". If your test seemed to pass, check that the host actually changed.
  • "Include subdomains" also catches previews. Preview deployments live on subdomains of your pages.dev host, so with that option on they redirect to production too. Previews already get X-Robots-Tag: noindex by default, so you can leave the option off if you still need them.

A Worker or advanced-mode _worker.js can also do the redirect. Google only sees the HTTP response, so any method works as long as every URL gets a 301 or 308 to its exact counterpart. Boloop's account has no Bulk Redirect list for its pages.dev host, yet every page answers 301 to the same path on the new domain, which suggests the site's own code handles it. Whichever method you use, test it the way Google sees it (see the commands below).

What must not be redirected?

Keep the Search Console HTML verification file answering 200 on the old host. Google's verification help says Search Console doesn't follow redirects when it looks for this file, and won't follow redirects to another domain. Search Console also re-checks verification from time to time. A blanket redirect can therefore quietly unverify the old property, which is the property you need to file the Change of Address.

Options, in order of simplicity:

  • Exempt the verification file path, for example /google<token>.html, from the redirect, so it answers 200 on both hosts. Boloop does this.
  • Or add a second verification method that survives the move. Google suggests HTML tag verification when the whole site redirects elsewhere, because tag methods follow the redirect to the page users land on. Check that the tag is on the new domain's home page.

Also think about robots.txt on the old host. Google can only see a redirect if crawling is allowed, so the old host must never answer Disallow: /. Either redirect robots.txt as well or keep a permissive file. Boloop keeps a 200 robots.txt on pages.dev that allows crawling and lists the new sitemap URL.

What has to change on the new domain at the same moment?

Everything that names a URL has to name the new host. Google's site-move guide asks for:

  • a self-referencing rel="canonical" on every new URL
  • hreflang alternates that use the new URLs (all language versions, plus x-default)
  • a sitemap whose <loc> entries are all on the new host, and a Sitemap: line in robots.txt that points to it
  • internal links that use the new host, or relative paths

On a Pages site that builds absolute URLs from a setting (Boloop uses a PUBLIC_ORIGIN variable), add JSON-LD url/@id values, RSS feed links and any llms.txt to that list. Each of them carries the old host until the setting changes and the site is redeployed.

On 9 November 2026, a day after the switch, Boloop's article pages carried a canonical, four hreflang links and JSON-LD on getboloop.com, and all 228 sitemap URLs were on the new host and returned 200.

How do I test the move the way Google sees it?

Request the old URLs without following redirects, and check the status code and the Location header. Then check that every new URL in the sitemap returns 200.

OLD=https://project.pages.dev
NEW=https://example.com

# 1. A deep link and a query string keep path and query, with a permanent code
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" "$OLD/blog/some-post"
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" "$OLD/blog/some-post?ref=x"

# 2. The verification file answers 200 on the old host (no redirect)
curl -s -o /dev/null -w "%{http_code}\n" "$OLD/google<token>.html"

# 3. robots.txt on the old host does not block crawling
curl -s "$OLD/robots.txt"

# 4. Every sitemap URL on the new host is on the new host and returns 200
curl -s "$NEW/sitemap.xml" | grep -oE '<loc>[^<]+' | sed 's/<loc>//' \
  | xargs -P 8 -n1 curl -s -o /dev/null -w "%{http_code}\n" | sort | uniq -c

# 5. A page names itself on the new host
curl -s "$NEW/blog/some-post" | grep -oE '<link[^>]*rel="canonical"[^>]*>'

Look closely at query strings. In Boloop's check, a tracking parameter on the home page got a 301, but list pages with ?page= or filter parameters answered 307, which is a temporary redirect. Google's redirects documentation says only permanent redirects act as a strong canonical signal. That's acceptable for URLs you never wanted indexed, but every URL that should carry ranking needs a 301 or 308.

How do I use Change of Address for a pages.dev site?

Open the Change of Address tool in the old https://<project>.pages.dev/ property and choose the new domain's property. Google's help sets the requirements:

  • You must be a verified owner of both properties, using the same Google account.
  • The tool works only on properties at the domain level, with no path. You can't verify a Domain property for pages.dev, because you don't control its DNS, so the old site is the URL-prefix property https://<project>.pages.dev/. That counts as domain-level because it has no path.
  • The tool checks that a few pages return 301 before it accepts the move.
  • The move notice lasts 180 days, and Google asks you to keep the redirects for at least that long.

For the new domain, a Domain property verified by a DNS TXT record covers every subdomain and protocol. Submit the new sitemap there. Google says you can drop the old sitemap once the new one is in. If you keep the old one, warnings that its URLs redirect are expected.

Should I disable, block or noindex the pages.dev host instead?

No, not if the old URLs were ever indexed. Forum answers often suggest switching the pages.dev domain off or putting it behind Cloudflare Access. Both remove the redirect Google needs to follow, and neither passes anything to the new domain. A robots.txt block has the same flaw, because Google can't crawl the redirect. A noindex header (X-Robots-Tag via _headers) drops old pages from results without telling Google where they went.

Use noindex only for a pages.dev copy that was never indexed and that you want to keep reachable, or for preview deployments. For anything Google has already indexed, redirect it.

How long does it take, and what's normal?

Google's guide says a medium-sized site can take a few weeks or more before Google mostly shows the new URLs. Every old URL has to be recrawled once for the move to finish. During that time:

  • Old pages.dev URLs may still appear in results. Google describes this as normal: after a permanent redirect, the old URL can stay as an alternate name for a while.
  • Rankings may move up and down while Google recrawls.
  • Old-property reports drop while the new property's reports rise. Watch both.

Keep the redirects for at least a year. Google gives that as the general minimum, and suggests keeping them indefinitely if you can.

What about Bing and IndexNow?

Bing works from the redirects. Microsoft community replies from 2025 report that Bing Webmaster Tools' Site Move tool is no longer available, so verify the new domain in Bing Webmaster Tools and submit its sitemap.

IndexNow needs a key file on the new host, and the first submission may be refused. When Boloop submitted the new domain's sitemap URLs on 9 November 2026, IndexNow answered HTTP 403 SiteVerificationNotCompleted, even though the key file was live and matched. A retry about five minutes later returned 200. So if you see that error, wait and retry before you assume the key is broken.

Short checklist

  1. Add the custom domain to the Pages project and wait for it to show as Active.
  2. Change your site's base-URL setting, redeploy, and confirm that the canonical, hreflang, sitemap, robots.txt Sitemap line, JSON-LD and feeds all name the new host.
  3. Verify the new domain in Search Console with the same Google account that owns the old property.
  4. Add a 301 from <project>.pages.dev/* to the same path on the new domain, keeping query strings. Exempt the verification file, and don't block the old robots.txt.
  5. Test with the curl commands above: deep links, query strings, verification file, all sitemap URLs.
  6. File a Change of Address from the old URL-prefix property, and submit the new sitemap.
  7. Ask Search Console to index a few key new URLs, and submit them to IndexNow once the host verifies.
  8. Keep the redirects for at least a year, and watch both properties for a few weeks.

FAQ

Does a 301 lose PageRank? No. Google's site-move guide says 301s and other permanent redirects don't cause a loss in PageRank.

Can I just rely on canonical tags pointing at the new domain? They help, but Google treats a canonical as a hint. A permanent redirect is the stronger signal, and the Change of Address tool expects redirects to be in place.

Do I need Change of Address if I only switch www and non-www? No. Google says the tool isn't for www and non-www moves on the same domain, for http to https, or for path changes within a site.

Will Google keep showing my pages.dev links? For a while, possibly. Old URLs can appear as alternate names after a redirect. They fade as Google recrawls and as links get updated, so change the links you control, like your X profile and directory listings, to the new domain.

Sources

  • Cloudflare Docs, "Redirecting *.pages.dev to a Custom Domain": https://developers.cloudflare.com/pages/how-to/redirect-to-custom-domain/
  • Cloudflare Docs, "Redirects" (_redirects feature support and Functions note): https://developers.cloudflare.com/pages/configuration/redirects/
  • Google Search Central, "Site moves and migrations": https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
  • Google Search Central, "Redirects and Google Search": https://developers.google.com/search/docs/crawling-indexing/301-redirects
  • Search Console Help, "Change of Address tool": https://support.google.com/webmasters/answer/9370220
  • Search Console Help, "Verify your site ownership": https://support.google.com/webmasters/answer/9008080
  • Septune, "Cloudflare Pages SEO: robots.txt, the www redirect and the pages.dev copy" (preview noindex default, Include subdomains): https://www.septune.dev/hosting/cloudflare-pages
  • Microsoft Tech Community, "Site Move Tool – Bing Webmaster Tools – link does not work": https://techcommunity.microsoft.com/discussions/bing/site-move-tool---bing-webmaster-tools---link-does-not-work/4203220

Related on Boloop: Why does Google verification fail when the verification file is already on the website? · The sitemap opens. Why does Search Console still say it could not fetch it?.