None of these are obvious bugs. They're the result of how the engine's physics interacts with iOS-specific runtime behavior that doesn't show up in desktop testing.

After shipping a 2D physics-based ricochet game built on Cocos Creator 3.x to the App Store, here's the short list of things I'd configure differently if I were starting over.

1. ProMotion silently changes your simulation

iPhone 13 Pro was the first iPhone with ProMotion, and every Pro model since has it. ProMotion means the display refreshes at up to 120Hz. WebViews and native runtime loops driven by CADisplayLink follow that refresh rate, which means requestAnimationFrame — and the Cocos Creator game loop bound to it — can fire up to 120 times per second on these devices.

If your physics integration uses the per-frame delta time directly — velocity += accel * dt; position += velocity * dt — your simulation now runs at a different effective resolution on a 120Hz device than on a 60Hz device. Same starting state, same input, slightly different physical outcome. Players on newer iPhones experience a subtly different game.

The fix is to lock physics to a fixed timestep, decoupled from rendering. In Project Settings → Physics 2D, set the Fixed Time Step explicitly (1/60s is the standard choice):

import { PhysicsSystem2D } from 'cc';

PhysicsSystem2D.instance.fixedTimeStep = 1 / 60;

Rendering still happens at whatever rate the device offers. Physics ticks at 60Hz regardless. Behavior becomes consistent across devices.

2. Don't integrate with variable dt

Even on a constant 60Hz display, the actual frame interval can vary — a thermal-throttled iPhone can drop to 45fps mid-game, or hit 30fps if other apps are competing for CPU. The classic accumulator pattern handles this without breaking the simulation:

const FIXED_DT = 1 / 60;
let accumulator = 0;

update(deltaTime: number) {
  accumulator += deltaTime;
  while (accumulator >= FIXED_DT) {
    this.stepPhysics(FIXED_DT);
    accumulator -= FIXED_DT;
  }
  // Optional: interpolate render position using accumulator / FIXED_DT
}

Cocos Creator's built-in physics system does this internally once you configure a fixed time step. But if you're running any of your own integration — custom forces, custom motion on non-rigidbody entities, gameplay logic that touches positions — apply the same pattern there. The moment any part of your simulation uses raw deltaTime, you've reintroduced the inconsistency you just fixed.

3. CCD is not on by default, and you usually want it

A projectile moving at 1000 px/s in a 60Hz simulation moves about 16.7 px per frame. If your wall collider is 10 px thick — or your projectile is small and your wall is at an angle — there's a real chance the projectile is in front of the wall on frame N and behind it on frame N+1, with no collision detected in between.

Discrete collision detection misses these. The fix is continuous collision detection, which in box2d terms means setting the bullet flag on the rigid body:

const rb = this.getComponent(RigidBody2D);
rb.bullet = true;

Two things to know:

• CCD has a real CPU cost. Apply it only to bodies that actually move fast — typically the player projectile, not every dynamic body in the scene.

• It only protects against passing through static and kinematic bodies. Two CCD-enabled dynamic bodies can still miss each other under box2d's defaults.

If you have geometry that's both fast-moving and dynamic-on-dynamic, supplement with manual raycasts between frames. Sample the start and end positions, fire a raycast along that segment, snap to the first hit.

4. Touch input lands later than you think

A user taps the screen. The native touch event arrives at the WebView. WebView forwards it to JavaScript. Your input handler runs. Cocos Creator's event system dispatches it on the next tick. Your physics responds on the tick after that.

That's two to three frames of latency between the finger landing and the projectile reacting. At 60Hz that's 33-50ms — noticeable in a precision physics game where the player is reading visual feedback to aim.

You can't eliminate the WebView → JS hop, but you can avoid adding more delay:

• Don't queue input into a buffer that's drained on the next physics tick. Handle it in the same tick if the input affects current-frame simulation.

• For aiming-style mechanics, render a preview of the trajectory the moment the touch starts, and only commit to a physics force on release. The visual responsiveness masks the input lag — by the time the player releases, they've already been seeing what would happen.

5. Background/foreground destroys your physics state

When the user switches to another app and comes back, the JS event loop has been suspended for an arbitrary duration — seconds, minutes, hours. The next update() call receives a delta time that reflects that entire pause.

If you pass that delta unfiltered into your physics step, the accumulator from section 2 runs hundreds or thousands of fixed steps in a single tick. The game freezes for a moment, then resumes with the projectile teleported across the level — through walls, past triggers, anywhere.

Two complementary fixes:

// Clamp delta to prevent runaway accumulation
update(deltaTime: number) {
  const safeDt = Math.min(deltaTime, 0.1);
  // ... use safeDt for physics
}

// Pause physics on visibility change
document.addEventListener('visibilitychange', () => {
  PhysicsSystem2D.instance.enable = !document.hidden;
});

The clamp protects you from runaway dt. The visibilitychange handler is cleaner — physics genuinely shouldn't tick when the user can't see the game. Use both.

6. Determinism is fragile, and you probably don't need it

If you ever want replay validation, network sync, or "the same level always plays out the same given the same input," you need deterministic physics. Floating-point math across iOS device generations — and especially across iOS vs Android — is not guaranteed to produce bit-identical results, even with a fixed timestep.

This is solvable: fixed-point math, integer-only simulation, or running physics on a server. Each path is heavyweight.

For most single-player physics games, the right answer is to not need determinism. Save state snapshots instead of replays. Validate completion server-side based on outcomes (level cleared, score reached) rather than exact motion paths. Build replay sharing as a video, not a deterministic simulation.

Pre-ship checklist

Before submitting a Cocos Creator 2D physics game to App Review, I'd now check:

• Physics fixed timestep is set explicitly, not left to default

• Fast-moving rigid bodies have bullet = true

• Input handlers process within the same tick as the affected physics step

• deltaTime is clamped, and physics pauses on visibilitychange

• Tested on at least one ProMotion device (iPhone 13 Pro or later) and one older device

None of this is obscure. It's just easy to miss when desktop preview looks perfect.

The game these notes come from is Juicy Ricochet — a Cocos Creator 3.x project I shipped to iOS. Most of what's above is the result of behavior I didn't see until I was running on a real iPhone in real hands. Playable in the browser at phyfun.com.

By the time I'd worked through what was happening, I'd learned more about WordPress URL parameter handling than I wanted to know. This post is the technical breakdown, in case you've hit the same warning.

The symptom

Search Console's exclusion report showed roughly a thousand URLs that all pointed back to the same canonicals:

https://example.com/some-article/

But the affected URLs were variants like:

https://example.com/some-article/?wptouch_switch=desktop&redirect=...
https://example.com/some-article/?wptouch_switch=mobile&redirect=...

Each canonical URL had two or three duplicate variants Google had crawled and decided to exclude — but without removing them from its index queue. They sat in "Excluded" purgatory, eating crawl budget, and kept reappearing because Google would re-crawl them periodically.

Diagnosis

The query parameter pattern ?wptouch_switch= was the giveaway. WPTouch is a WordPress mobile theme plugin that lets a single site serve different layouts to mobile and desktop visitors. It includes a "switch view" link at the bottom of every page so a mobile user can force the desktop layout (or vice versa).

That link works by appending a query parameter to the current URL:

<a href="?wptouch_switch=desktop&redirect=/some-article/">View desktop site</a>

When the user clicks, WPTouch sets a cookie indicating their preference, then redirects them. From a user's perspective, this is invisible. From Google's perspective, it's a parade of new URLs being introduced into the crawl queue every time WPTouch renders a footer.

Googlebot finds the link in the HTML, follows it, sees content nearly identical to the parameter-free URL, and files it as a duplicate.

The same canonical URL having multiple duplicates would normally be fine — Google picks one and ignores the others. The problem here was scale. With WPTouch's switch link on every page, every indexed URL got at least one extra duplicate. For a site with several thousand pages, that meant several thousand extra URLs in Search Console reports indefinitely.

The layered fix

There's no single setting that fixes this. The right approach is a layered defense — each layer reduces the problem somewhat, and combined they eliminate it.

Layer 1: robots.txt

The first line of defense is preventing Googlebot from crawling these URLs in the first place. Add this to robots.txt:

User-agent: *
Disallow: /*?wptouch_switch=
Disallow: /*&wptouch_switch=

The two rules cover both cases — where wptouch_switch is the first parameter (preceded by ?) and where it's a subsequent parameter (preceded by &).

This stops new crawls of these URLs but doesn't remove what's already indexed.

Layer 2: canonical tags

WordPress SEO plugins (Yoast, Rank Math, AIOSEO) usually add rel="canonical" tags to pages, and they usually point to the clean URL by default — but you should verify. Open one of the flagged URLs in your browser, view the source, and confirm:

<link rel="canonical" href="https://example.com/some-article/" />

Note the canonical URL has no ?wptouch_switch= parameter. If your SEO plugin is generating canonicals that include the parameter, you have a deeper problem and need to fix the plugin configuration or override.

For the case where you can't rely on the plugin's default, a small filter in your theme's functions.php works:

add_filter('wpseo_canonical', function($canonical) {
    return strtok($canonical, '?');
});

This strips any query string from the canonical URL Yoast generates. Swap the filter name for other SEO plugins (rank_math/frontend/canonical, aioseo_canonical_url, etc.).

Layer 3: 301 redirect for the parameter

For maximum cleanup, redirect ?wptouch_switch= requests to the parameter-free version. This is more aggressive than the previous layers because it changes user behavior too — but in this case it's safe, because by the time the redirect runs, real users have already had their cookie set on the click.

Add to .htaccess:

RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)wptouch_switch=
RewriteRule ^(.*)\( /\)1? [R=301,L]

The trailing ? in the rewrite target strips the existing query string. The R=301 makes it a permanent redirect, which is what tells Google to deindex the parameter version over time.

Layer 4: Search Console URL Removal (cleanup acceleration)

For URLs already flagged in Search Console, the layered fix above will eventually clear them — but it can take weeks for Google to re-crawl every duplicate and confirm the change. To accelerate cleanup:

1. Go to Search Console → "Removals" tool.

2. Submit a "Temporarily remove URL" request with a path prefix matching wptouch_switch. Use the "Remove all URLs with this prefix" option.

3. Wait 24 hours for Google to honor the request.

This doesn't remove URLs from Google's database — it just hides them from search results for around six months, which is enough time for the canonical and robots fixes to take full effect.

Verification

After deploying all four layers, the cleanup timeline looked roughly like this:

• Day 1: All four layers in place, redeployed.

• Day 3: robots.txt fetched by Googlebot. New crawls of ?wptouch_switch= URLs stopped showing up in server logs.

• Day 7: Search Console "Excluded" report stable; no new duplicates being added.

• Day 21: Excluded count starts to drop as Google re-crawls existing duplicates and confirms the 301.

• Day 60: Excluded count down to a small residual; the warning effectively cleared.

The total work was maybe two hours, including the time to write and test the .htaccess rule. The payoff is more than aesthetic — Google's crawl budget is now spent on real content rather than parameter variants, and the Coverage report is finally a useful diagnostic surface again.

Lessons

A few things worth internalizing for future WordPress URL hygiene:

Audit query parameter sources. WPTouch is the most common offender I've seen, but other plugins introduce similar patterns — caching plugins, geolocation plugins, social sharing widgets, A/B testing tools. Anything that adds ?something=value links into your rendered HTML can do this.

Canonicals alone aren't enough. Most write-ups treat canonical tags as the complete solution. They aren't. Without robots.txt and the 301 layer, Google will still crawl, still index temporarily, and still report duplicates.

Path-prefix removal is underused. The Search Console URL Removal tool's prefix option is one of the few things that gives you fast-acting feedback during cleanup. Most operators don't know it exists.

Don't troubleshoot from a single browser. When you can't replicate the duplicate URL issue in your own browser (because you don't see the WPTouch link, or because your view is "desktop already"), you'll dismiss the warning. Always check Googlebot's view — Search Console's URL Inspection tool is the definitive source.

The next time Search Console surprises me with hundreds of new exclusions, the first thing I'm going to do is sort them by URL pattern. Almost every "sudden" duplicate problem turns out to have a single common parameter at the root.

Why I Migrated

The trigger was multi-platform export. LayaAir can technically output to multiple platforms, but the tooling and documentation around non-WebGL targets (WeChat mini games in particular) had become thin. Cocos Creator has invested heavily in mini game export and now powers the majority of top-ranked WeChat mini games, which tells you where serious mobile developers have converged.

If you only need WebGL and nothing else, LayaAir remains a reasonable choice. It's lighter, faster to get started, and sufficient for most small-to-medium browser games. The decision to migrate only made sense because my project roadmap included iOS, Android, and WeChat mini game targets.

Scene System Differences

This was the biggest conceptual shift.

LayaAir treats scenes as flexible containers. You instantiate nodes, add them to the stage, and manage the tree manually. It feels natural if you come from a DOM-manipulation background.

Cocos Creator uses a more opinionated scene graph built around the prefab system. The engine expects most reusable visual elements to be prefabs, instantiated via the instantiate() API, and managed through a component-based lifecycle similar to Unity.

My first Cocos project had scenes that looked like LayaAir scenes translated literally — lots of manual node instantiation, minimal prefabs. Code size roughly halved once I refactored to proper prefab usage.

The core pattern:

typescript

// LayaAir style (works in Cocos but misses the point)
const node = new Node();
node.addComponent(Sprite);
node.parent = this.node;

// Cocos Creator idiomatic
const instance = instantiate(this.prefab);
instance.parent = this.node;

Asset Loading and Bundles

LayaAir's asset loading is flexible but leaves most optimization to the developer. You decide what to preload, what to lazy-load, what to release.

Cocos Creator introduces an AssetBundle system that handles most of this declaratively. Bundles can be packaged with the main build, loaded on demand, or fetched from a CDN. For WeChat mini games with 4 MB initial package limits, bundles are not optional — they're the only way to stay under the size cap.

The common mistake when starting with bundles is over-splitting. I initially created a bundle per scene plus several feature bundles, ending up with 20+ bundles that each required a network round trip to load. The right granularity is coarser: group by major gameplay section, not by individual scene.

Loading a bundle in code:

typescript

assetManager.loadBundle('gameplay', (err, bundle) => {
  bundle.load('prefabs/Enemy', Prefab, (err, prefab) => {
    const enemy = instantiate(prefab);
    this.node.addChild(enemy);
  });
});

TypeScript Experience

Both engines support TypeScript. The experience is noticeably better in Cocos Creator.

Decorators for components and serialized properties are mature and well-documented:

typescript

const { ccclass, property } = _decorator;

@ccclass('Enemy')
export class Enemy extends Component {
  @property(Number)
  health: number = 100;

  @property(Node)
  target: Node = null;

  start() {
    this.schedule(this.updateTarget, 0.5);
  }

  updateTarget() {
    // logic
  }
}

Autocomplete works reliably across the engine API, decorator-based property editors generate correctly in the inspector, and type inference for component references is accurate.

LayaAir's TypeScript support exists but feels bolted on. The build process requires more manual configuration, and editor integration is less polished.

The WeChat Mini Game Pipeline

This is where Cocos earns its reputation. The WeChat build target works with minimal configuration for most projects:

1. Set build target to "WeChat Game" in the build panel

2. Configure the AppID and basic manifest

3. Build — output is a ready-to-upload build/wechatgame folder

The constraints you need to understand before the first build:

• Initial package size: 4 MB hard limit

• Total package size: 20 MB with subpackages

• Memory limit: roughly 500 MB on most devices, less on older ones

• File system: read-only for bundled files, writable scratch area for user data

• Networking: HTTPS-only, requires pre-declared domain allowlist

Texture compression matters enormously here. I reduced initial package size by 40% just by switching from PNG to ETC1/ETC2 compression for in-game sprites. UI assets stay as PNG for quality reasons; gameplay assets use compressed formats.

Apple Silicon Editor Issues

Developing on an M1/M2 Mac is mostly smooth. Cocos Creator runs natively on Apple Silicon, builds are fast, and the profiler works correctly.

One consistent issue: the editor occasionally loses keyboard focus on its main window. You click a panel, type something, nothing happens — the window technically has focus but isn't receiving input. Clicking the title bar restores it.

This appears to be a macOS window management interaction, not a Cocos-specific bug, but it's frequent enough to note. Nothing has been lost from it, but it's a papercut that adds up over a long day.

Animation System

LayaAir's animation system is minimal — tween properties over time with some curve support.

Cocos Creator's Animation Editor is closer to a dedicated animation tool. Multi-track timelines, frame events, and clip management are all built in.

The tradeoff: simple tweens that are one line in LayaAir sometimes require opening the Animation Editor in Cocos. For a game with significant UI or character animation, the Cocos editor is a large productivity win. For a game with only a few tween effects, LayaAir is faster.

Build Times

Cocos Creator builds are slower than LayaAir builds for equivalent project sizes. An initial build of a medium project takes a few minutes. Incremental builds are faster but still not instant.

Practical workaround: rely heavily on the in-editor preview for iteration. Full builds are for validating export-target-specific behavior — mini game memory usage, iOS retina rendering, etc. — not for day-to-day development.

Documentation Reality

Cocos Creator's documentation is extensive but fragmented. Official docs, forum posts, and community tutorials sometimes disagree, and older tutorials may reference APIs that changed between major versions.

The Chinese-language community is significantly larger than the English community. Some of the best debugging resources are in Chinese forum posts and Chinese YouTube videos. If you're an English-only developer, expect to use translation tools regularly.

LayaAir has similar dynamics but smaller overall volume. For English documentation availability, neither engine is ideal.

Decision Framework

Migrate to Cocos Creator if:

• You need WeChat, Douyin, or other Asian mini-game platforms

• You need first-class iOS/Android export without relying on third-party wrappers

• You're building something with significant animation or UI complexity

• You want component-based architecture similar to Unity

Stick with LayaAir if:

• Your target is WebGL only

• Your project is small and iteration speed matters more than platform flexibility

• You're more productive in a lightweight, flexible scene model

Takeaway

Three weeks of reduced productivity during the migration transition, then the new workflow became natural. The project is now running in production on phyfun.com, a small browser games platform I maintain, and the Cocos-based version is easier to extend than the LayaAir version ever was.

If you're considering this migration, start with a small throwaway project. The common early mistakes — over-instantiating nodes, under-using prefabs, mis-configuring bundles — are cheap to make in a learning project and expensive to make in production code.

I run a portfolio of small content and game sites, most of them hosted on SiteGround. For a long time I used SiteGround's built-in CDN — it ships in the control panel, it's one toggle to enable, and for a while it worked fine.

Then it didn't.

Over a few weeks I started seeing intermittent "Not Secure" warnings on my sites. A page would load normally, refresh, and suddenly the browser would warn about an insecure connection. Refresh again and it would be fine. Not every user hit it, not every page, not every time — but often enough that I couldn't ignore it.

After some diagnosis, I decided to stop trying to fix the behavior of a black box and migrate to Cloudflare. I tested the process on one site first (idognames.com) and then rolled it out across the rest of my portfolio.

This post walks through the setup, the configuration decisions that matter, and the real gotchas I ran into — so if you're doing the same migration, you don't have to learn them the hard way.

Why leave SiteGround's CDN?

SiteGround's CDN is convenient, but it's also opaque. When it works, it works. When it doesn't, you're mostly at the mercy of support tickets.

My specific trigger was intermittent HTTPS issues. But the broader reasons Cloudflare is worth considering:

• Global edge network — Cloudflare has 300+ points of presence worldwide; SiteGround's CDN is far smaller

• Free tier covers real-world needs — unlimited bandwidth, free SSL, basic DDoS protection

• Granular cache control — cache rules, page rules, purge-by-URL, all on free plan

• One dashboard for multiple sites — useful if you, like me, run a portfolio

• Better ecosystem — R2, Workers, Pages, Images, Zaraz are all one click away if you need them later

Cloudflare also hides your origin server IP, which is a nice-to-have if you're paranoid about being targeted directly.

Pre-migration checklist

Before touching anything, do this:

1. Confirm your SSL certificate is active on SiteGround. Go to Site Tools → Security → SSL Manager. You should see an active Let's Encrypt (or other) certificate. This is important because after the migration, SiteGround still serves the origin — the certificate stays where it is.

2. Note your server IP. Site Tools → Site → Site Information. Write down the "Site IP" value. You'll need it to verify DNS records later.

3. Document any custom .htaccess rules. If you have custom redirects, force-HTTPS rules, or security headers, screenshot them. They'll still work after the migration, but it's worth having a reference.

4. Pick a test site. Don't migrate all your sites at once. Pick one you can tolerate being offline briefly — ideally not your highest-traffic one. I used a mid-traffic niche content site as my test bed.

Step 1: Add your site to Cloudflare

Sign up for a free Cloudflare account. Click "Add a site", enter your domain, and pick the Free plan — for most small to medium sites this is genuinely enough.

Cloudflare will then scan your domain's DNS records and show you what it found. This is where the first gotcha shows up — see the next section.

Step 2: DNS records review (the real gotcha section)

When Cloudflare scans your DNS, it pulls from multiple sources — including historical DNS databases. That means the list you're shown may include records that haven't been live in years.

You need to manually check every record before proceeding.

Things to look for:

• All your main A records should point to your current server IP. If you see an A record pointing to a different IP, investigate before keeping it. It might be a legitimate separate service, or it might be a ghost from an old setup.

• Subdomains you don't use can be deleted. I had autoconfig, autodiscover, ftp, mail, and ssh subdomains imported automatically. If you don't use these services under your domain, delete the records — they're noise.

• MX records for email should stay as "DNS only" (gray cloud). Cloudflare's proxy doesn't handle SMTP; if you proxy mail records, email breaks.

• TXT records for SPF, DKIM, DMARC stay as "DNS only" too.

• Web-serving A and CNAME records should be set to "Proxied" (orange cloud) — this is what actually routes traffic through Cloudflare's CDN.

Tip: Cloudflare's auto-scan is a starting point, not the final answer. Treat it like a pull request from a stranger: review every line before merging.

Step 3: Change nameservers

Cloudflare gives you two nameserver addresses, something like west.ns.cloudflare.com and desi.ns.cloudflare.com.

Go to your domain registrar (wherever you bought the domain — Namecheap, GoDaddy, Porkbun, etc.) and replace the existing nameservers with the two Cloudflare gave you.

Save, and wait.

DNS propagation can take anywhere from 15 minutes to a few hours, occasionally up to 24. You can check progress with:

dig yourdomain.com NS +short

When you see the two Cloudflare nameservers in the output, propagation is complete for your current DNS resolver. Cloudflare will also email you when it detects that the nameserver change is live and your site is fully active.

Step 4: SSL/TLS configuration

This is the part most people get wrong. Open Cloudflare → SSL/TLS → Overview.

You'll see four modes: Off, Flexible, Full, Full (strict). Here's what each actually does:

• Off — no HTTPS. Don't.

• Flexible — browser to Cloudflare is HTTPS, Cloudflare to your origin is plain HTTP. This will break your site if your origin redirects HTTP to HTTPS (which most do), because you'll end up in a redirect loop.

• Full — both legs are HTTPS, but Cloudflare doesn't strictly verify your origin certificate. Tolerant of self-signed or expired certificates.

• Full (strict) — both legs HTTPS, and Cloudflare verifies your origin certificate is valid and not expired.

Set it to Full (strict). Your SiteGround-managed Let's Encrypt certificate is a valid, publicly-trusted certificate, so strict mode works out of the box. This is the most secure option, and there's no reason to accept less if your origin certificate is good.

Then go to SSL/TLS → Edge Certificates and configure:

• Minimum TLS Version: TLS 1.2 — The default is TLS 1.0, which has been deprecated for years. Raise it to 1.2.

• TLS 1.3: On — Modern, faster, more secure.

• Always Use HTTPS: On — Any HTTP request gets 301-redirected to HTTPS at the edge, before it even reaches your origin.

• Automatic HTTPS Rewrites: On — If any of your pages have http:// links in them (old content, for example), this rewrites them on the fly to https://, avoiding mixed content warnings.

These five settings are the minimum I'd consider "correct" for a modern site in 2026.

Step 5: Caching

Cloudflare's free tier caches static assets by default — images, CSS, JS, fonts. HTML pages are not cached by default.

For most content-heavy sites, you want HTML cached too. The simplest way:

1. Go to Caching → Configuration

2. Make sure "Caching Level" is set to Standard

3. Create a Cache Rule under Rules → Cache Rules: match yourdomain.com/*, action: "Cache eligible for cache", with an edge TTL of 2 hours (or whatever fits your update cadence)

If you update content frequently, you can shorten the TTL, or use Cloudflare's "Purge Everything" button after publishing.

Things I ran into

A few smaller gotchas worth mentioning:

SiteGround's HTTPS Enforce and Cloudflare's "Always Use HTTPS" are not the same layer. SiteGround enforces HTTPS at the origin server. Cloudflare enforces it at the edge. Having both on is fine — they don't conflict, they stack. Cloudflare gets the request first and redirects before the origin is touched.

SSL certificates are still managed by SiteGround. A common confusion: "if I'm behind Cloudflare, do I still need a certificate on my origin?" Yes. Your origin still needs a valid certificate — that's what Full (strict) mode verifies. Keep your Let's Encrypt certificate renewing normally on SiteGround.

Don't forget to turn off SiteGround's CDN. After the migration, SiteGround's own CDN is no longer doing useful work. Disable it in Site Tools → Speed → CDN. Leaving it on can create an unnecessary extra hop, though it won't actively break things.

Check caching behavior after migration. Your cache-hit ratio will start low and grow over time as Cloudflare warms up. Don't judge performance in the first hour — give it a day or two.

Before and after

I didn't run formal benchmarks, but subjectively:

• The intermittent "Not Secure" warnings that triggered the migration are gone

• Cache control is dramatically more flexible (I can now cache HTML, which SiteGround's CDN didn't do for me)

• I can see actual traffic and cache analytics in the Cloudflare dashboard

• The origin is now hidden behind Cloudflare's IPs, which is a small but real security improvement

The migration itself took maybe 30 minutes per site once I'd done the first one. The hardest part was getting the first one right and confident enough to replicate the pattern.

Should you migrate?

Cloudflare's free tier is a better CDN than most hosts bundle by default — and that's not controversial, it's just the reality of the market. If you're on SiteGround and your CDN is working fine for you, there's no urgency. But if you're hitting intermittent issues, or if you just want more control and visibility, Cloudflare is a solid replacement.

I've now migrated my entire portfolio. No regrets so far. Starting with one test site was the right call — it gave me a repeatable playbook before I touched the sites I actually care about.

If you've done this migration and ran into something I didn't cover, I'd love to hear about it in the comments.

Playing around with small games in the browser: phyfun.com My game portfolio: marvingames.com