GitHub Pages vs Netlify vs Cloudflare Pages (Real Limitations for Business Sites)
The redirect problem (why this site uses meta-refresh stubs)
GitHub Pages does not support server-side 301 redirects from _redirects the way Netlify does. This repo ships hundreds of _redirects rules for Netlify compatibility, but live GitHub Pages relies on meta-refresh HTML stubs + canonical tags — weaker SEO signal.
| Host | Real 301 redirects | Custom headers |
|---|---|---|
| GitHub Pages | No (Jekyll redirect plugins limited) | Limited |
| Netlify | Yes (_redirects, netlify.toml) |
Yes |
| Cloudflare Pages | Yes + Workers | Yes via Workers |
Recommendation: Cloudflare in front of Pages (or migrate origin to Cloudflare Pages) for real 301s.
This is the single biggest reason we maintain dual redirect infrastructure. When we migrated hundreds of blog URLs during a permalink cleanup, Netlify-style _redirects worked in staging but GitHub Pages production required generating HTML stub files with <meta http-equiv="refresh"> and <link rel="canonical">. Google eventually follows these, but link equity transfer is slower and less reliable than a true 301.
For client sites where SEO history matters — established .com.np domains with indexed URLs — do not accept meta-refresh as a long-term strategy. Budget either Netlify, Cloudflare Pages, or Cloudflare Workers rewrite rules in front of GitHub Pages.
Build & bandwidth
- GitHub Pages: free for public repos, 10GB/month soft limits
- Netlify: generous free tier; build minutes capped
- Cloudflare Pages: unlimited bandwidth on free tier; 500 builds/month
Expanded comparison table
| Factor | GitHub Pages | Netlify | Cloudflare Pages |
|---|---|---|---|
| Free bandwidth | ~10GB soft cap | 100GB/month | Unlimited |
| Build minutes | Uses Actions minutes (public repo generous) | 300 min/month free | 500 builds/month |
| Custom domain + SSL | Yes | Yes | Yes |
| Branch previews | Manual / Actions workaround | Native | Native |
| Forms without backend | No | Netlify Forms | Needs Worker or third party |
| Edge functions | No | Edge Functions (limits) | Workers (generous free tier) |
| Nepal agency fit | Dev-heavy teams already on GitHub | Fast client handoffs | High-traffic static + global CDN |
Nepali SME brochure sites rarely exceed bandwidth caps on any platform. The decision usually hinges on redirects, previews, and who maintains the repo — not raw traffic volume.
When each wins
- GitHub Pages: open-source docs, personal sites tied to repo
- Netlify: agencies wanting fast deploy previews + forms
- Cloudflare Pages: global static sites + Workers edge logic
GitHub Pages — best when
- Site source is already in a public GitHub repository
- Team runs custom CI (GitHub Actions CI/CD guide) and wants artifact control
- Redirect churn is low or Cloudflare handles rewrites
- Budget is literally zero beyond domain registration
Limitations we live with on arjankc.com.np: no native _redirects, limited response header control, no built-in form endpoints, preview URLs require custom workflow.
Netlify — best when
- Agency delivers static sites to non-technical clients who need “connect repo → auto deploy”
- Contact forms must work without standing up a backend
- Branch preview links are part of the client approval process
-
_redirectsandnetlify.tomlheader rules are first-class
Netlify is the fastest handoff for Kathmandu agencies building campaign landing pages. Watch the 300 build-minute free cap if CI runs full test suites on every push — cache dependencies aggressively.
Cloudflare Pages — best when
- Global static delivery and unlimited bandwidth matter (media-heavy portfolios, download hubs)
- You need Workers for geo routing, A/B headers, or API proxies at edge
- Real 301 redirects without a separate redirect host
- DNS already on Cloudflare (Cloudflare DNS guide)
Trade-off: build pipeline differs from GitHub Actions Pages flow — plan migration time.
Decision methodology for client projects
We score each project on five factors:
| Factor | Weight | GitHub Pages | Netlify | CF Pages |
|---|---|---|---|---|
| SEO redirect needs | High | Low score | High | High |
| Client self-service deploy | Medium | Low | High | Medium |
| Existing GitHub CI investment | Medium | High | Medium | Medium |
| Form handling | Medium | None | Built-in | Custom |
| Long-term cost at scale | Low | High | Medium | High |
Example: Tourism landing page with 20 URLs and contact form → Netlify. Example: Developer portfolio tied to open-source repo → GitHub Pages + Cloudflare DNS. Example: High-traffic static catalog with geo pricing headers → Cloudflare Pages + Workers.
Headers, security, and compliance
Business sites increasingly need security headers (Content-Security-Policy, HSTS, X-Frame-Options). Platform support varies:
| Header control | GitHub Pages | Netlify | Cloudflare Pages |
|---|---|---|---|
_headers file |
No | Yes | Via _headers or Workers |
| HSTS preload | Limited | Configurable | Configurable |
| CSP for third-party scripts | Manual meta tags | _headers |
Workers or _headers
|
Nepali e-commerce sites integrating eSewa/Khalti scripts need CSP planning regardless of host — payment gateway domains must be allowlisted. See payment gateway integration.
Hybrid architecture we recommend
For established domains where migrating off GitHub Actions is costly:
- Keep GitHub Actions build pipeline
- Deploy artifact to GitHub Pages (or R2 + Pages)
- Put Cloudflare proxy in front for caching, SSL, WAF
- Implement 301 redirects via Cloudflare Bulk Redirects or Workers
This preserves our existing CI/CD investment while fixing the redirect gap without full platform migration.
Cost over 24 months
| Scenario | GitHub Pages | Netlify Pro | CF Pages + Pro DNS |
|---|---|---|---|
| Brochure site, low traffic | NPR 0 hosting | ~USD 19/mo if Pro needed | ~USD 20/mo if Pro |
| Agency with 10 client sites | NPR 0 (public repos) | Minutes/bandwidth pressure | Free tier often sufficient |
| E-commerce (static catalog) | Not suitable alone | Forms + redirects help | Workers for cart API |
Compare against WordPress TCO in WordPress vs static site business TCO. Static hosting wins on ongoing maintenance; WordPress wins on non-technical content editing for some clients.
Migration checklist
Moving between hosts:
- Export all redirect rules to a single source of truth
- Verify custom domain SSL provisioning before DNS cutover
- Test www vs apex resolution
- Purge old CDN cache after migration
- Submit updated sitemap in Search Console
- Monitor 404 rate for 30 days post-migration
For .com.np domains, nameserver changes at register.com.np follow the same timeline regardless of host — plan launches outside peak festival freeze periods if stakeholders are unavailable.
Common agency mistakes
- Choosing GitHub Pages for a client site with 200+ legacy URLs and no redirect plan
- Assuming
_redirectsin repo root works everywhere because Netlify docs say so - Skipping preview environments → layout bugs discovered on production
- Paying for Netlify Pro when Cloudflare free tier covers the actual requirement
- Ignoring website maintenance after handoff — deploy pipeline breaks when Node/Ruby versions drift
