Business Nov 13, 2026

How to Move a Website from GitHub Pages to Cloudflare Pages — Without Breaking It

I moved my newest site from GitHub Pages to Cloudflare Pages in a day. Here is the exact sequence that worked — including the step that failed first and the twelve-hour wait nobody warns you about.

If your website lives on GitHub Pages and it works, leave it alone. That is the first honest thing to say in a guide about moving away from it. GitHub Pages is free, it is reliable, and for a simple static site it asks almost nothing of you. Three of my sites still live there, including this one. But there comes a point where you need things GitHub Pages does not give you: proper redirect rules, control over headers, preview deployments, and a global edge network with security tools in front of it. That is when a move makes sense — and when it is worth doing carefully, because a migration done badly is how a working site goes dark on its best day.

I made this exact move in November 2026 with my fourth website, MythPost, a news and stories site I built in a single day. Forty-two articles, fifty-seven pages, one hundred sixty-one files. It went live on Cloudflare Pages the same evening, and the custom domain followed the next morning. Nothing broke, no page went missing, and search traffic never noticed the change. This guide is the sequence I actually used, including the step that failed on the first try and the long wait in the middle that nobody warns you about.

Step 1 — Decide why you are moving, in one sentence. Write it down before you touch anything. Mine was simple: I wanted Cloudflare's edge, redirect rules, and DNS in one place for a site that would publish daily and needed to survive traffic spikes. If your reason is only that Cloudflare sounds more serious, stop here. A migration is a small project with real risk, and fashion is not a reason to take it on. If your reason is a real capability you need — redirects, headers, preview links, or tighter security — the work is worth it, and the rest of this guide will get you there.

Step 2 — Audit the site before you move a single file. Open your built output folder — the finished HTML, CSS, images, and data files, not your source code — and make a list of everything that must survive the move. The files people forget are always the same ones: sitemap.xml, robots.txt, ads.txt if you run ads, the favicon, and any verification files. Check your internal links while you are there. On MythPost I checked every internal link before deploying, not after, because a broken link found after the move is a broken link your visitors already met. Count the files too, so you can confirm the same number lands on the other side. If your count does not match after deploying, stop and find the gap before you touch DNS.

Step 3 — Set up Cloudflare access the right way, once. Create your Cloudflare account and make a scoped API token with Pages and Zone and DNS permissions — only the permissions the job needs, nothing more. Store that token in a password manager or a proper secret store. Never paste it into a chat message, never commit it to a repository, and never email it to yourself. Sign in to the Cloudflare dashboard with Sign in with Google, not with a password you will forget or reuse. Access is the foundation of this whole move: if the token is loose, the site is loose, and no amount of careful deployment fixes that.

Step 4 — Deploy to the pages.dev address first, and verify it like a stranger. Create the Pages project and deploy your built folder to it — through a connected Git repository or a direct upload, whichever your workflow supports. You will get a yoursite.pages.dev address. Open it. Click through the homepage, a category page, and several inner pages. Confirm they return a proper 200 response and that the images and stylesheets actually load. This step is the whole secret of a safe migration: never point your real domain at a deployment you have not already opened with your own eyes. My deployment went up with all one hundred sixty-one files and the homepage, category hubs, and article pages all served correctly on the first check. Only then did I move on to the domain.

Step 5 — Attach the custom domain and move the nameservers. In Cloudflare, add your domain as a zone and attach it as a custom domain on the Pages project, including the www version, which Cloudflare points at your pages.dev address. Then go to your domain registrar and replace the nameservers with the two Cloudflare nameservers assigned to your zone. This is the step that needs patience. I made the nameserver change on the evening of November 10, and the zone did not go active until 10:59 AM the next morning — about twelve hours later. Nothing was wrong. That is simply how long propagation can take, and it varies by registrar and by region. Plan the move for a quiet day, not launch hour, and do not keep changing settings while you wait. Changing things mid-propagation only restarts the confusion.

Step 6 — Verify everything again, from scratch, on the real domain. Once the zone is active, open your custom domain in a fresh browser window, not a cached tab. Check the homepage and several inner pages. Check that the www version sends visitors to the main domain instead of showing a second copy of the site. Confirm the HTTPS certificate is active and the padlock shows. Fetch the sitemap, the robots file, and the ads.txt file at their real addresses and confirm each one returns its content, not an error page. If an advertising review is running on any of your sites, this check matters twice as much: a missing ads.txt during a review is a problem you created yourself, for free.

Step 7 — Tell Google the site has moved house. Open Search Console, resubmit your sitemap on the new host, and request indexing for your most important pages. Make sure your canonical tags point at the custom domain, not at the pages.dev address. Google follows the canonical, so this one line decides which address the search results show. Then leave it alone. Search Console will take its time re-crawling, and refreshing it every hour will not make it faster.

Now the honest pitfalls section, because the steps above are the clean version and reality is messier. First, my dashboard deploy failed. The Cloudflare dashboard sign-in hit a verification wall and would not let me deploy from the browser at all, so the direct-upload route through the API is what actually shipped the site. Have a second route ready before you start — a git-connected deploy or an API upload — because discovering your only route is blocked at midnight is a bad way to learn it. Second, the CNAME file: GitHub Pages reads a CNAME file in your repository to know your custom domain. Cloudflare ignores it completely. Attach the domain inside the Pages project instead, and do not assume a file you carried over is doing anything. Third, do not plan on redirecting the pages.dev address to your domain. The pages.dev address sits outside your zone, so your own redirect rules cannot catch it. Set your canonicals on the custom domain and stop worrying about the preview address. Fourth, do not delete the old GitHub repository yet. Keep it untouched for at least a week as your fallback. If anything looks wrong on the new host, you can point the domain back in minutes. Fifth, check your caching. Cloudflare caches aggressively by default, which is good for speed and bad for a founder who just fixed a typo and cannot see the fix. Learn where the purge button is before you need it in a hurry.

A final note on cost, because founders ask first. Cloudflare Pages has a free tier that covers a static site like this comfortably, and the DNS and SSL come with it. I spent nothing on the move itself. What it costs is an evening of careful work and a morning of patience while the nameservers propagate. That is a fair trade for the control you get on the other side — and if you are running the site as a business, control over your own front door is not a luxury. It is the job.

Done properly, a migration is the most boring success you will ever have. Nobody notices, no visitor writes in to congratulate you, and the site simply keeps working from a stronger foundation. That silence is the result you are aiming for. Move slowly, verify twice, keep the fallback, and let the numbers tell you it worked.

I run Grab AI Tool, ToolPixi, DailyWallPix, and MythPost — you can explore them from my ventures page, or reach me through the contact page.