Content Delivery Networks (CDNs) dramatically improve WordPress site speed by serving images, CSS, and JavaScript from globally distributed servers. But CDNs add complexity to backups and restoration—URLs change, assets live on external servers, and migrations require careful URL replacement to avoid broken images and missing files.

This comprehensive guide tackles the unique challenges CDNs create for WordPress backups. You’ll learn how CDN URL structures affect database backups, how to properly backup and restore CDN-enabled sites, and how to handle migrations without breaking asset links. Whether you use Cloudflare, MaxCDN, Amazon CloudFront, or another provider, you’ll understand exactly how to maintain bulletproof backups.
By the end of this tutorial, you’ll know how to backup CDN-configured sites correctly, restore them without broken assets, and test backups while preserving CDN functionality.
Understanding CDNs and WordPress
What is a CDN?
Traditional WordPress Hosting:
User in Australia → Server in USA → Slow (200ms+ latency)
With CDN:
User in Australia → CDN Edge Server in Sydney → Fast (20ms latency)
User in USA → CDN Edge Server in New York → Fast (15ms latency)
How CDNs Work:
- WordPress uploads image to server:
yoursite.com/uploads/logo.png - CDN plugin rewrites URL:
cdn.yoursite.com/uploads/logo.png - User requests image from CDN subdomain
- CDN serves cached copy from nearest server
- Fast delivery, reduced server load
Popular CDN Providers
Cloudflare (Most Popular):
- Free tier available
- Automatic SSL
- DDoS protection included
- DNS-based (proxies entire site)
- 275+ edge locations worldwide
StackPath (formerly MaxCDN):
- Pull CDN (caches on-demand)
- Custom CDN URLs
- Real-time cache purging
- Starting $10/month
Amazon CloudFront:
- AWS integration
- Pay-as-you-go pricing
- Global edge network
- Complex configuration
KeyCDN:
- Budget-friendly ($0.04/GB)
- Simple setup
- HTTP/2 support
- 34 edge locations
BunnyCDN:
- Very affordable ($0.01/GB)
- Fast performance
- WordPress plugin available
- 91 edge locations
CDN URL Structures
Subdomain CDN:
Original: https://yoursite.com/wp-content/uploads/image.jpg
CDN: https://cdn.yoursite.com/wp-content/uploads/image.jpg
Custom Domain:
Original: https://yoursite.com/wp-content/uploads/image.jpg
CDN: https://static.yoursite.com/wp-content/uploads/image.jpg
Third-Party Domain:
Original: https://yoursite.com/wp-content/uploads/image.jpg
CDN: https://d3abc123xyz.cloudfront.net/wp-content/uploads/image.jpg
Cloudflare (Transparent):
Original: https://yoursite.com/wp-content/uploads/image.jpg
CDN: https://yoursite.com/wp-content/uploads/image.jpg (same URL!)
How CDNs Affect WordPress Backups
Database URL Rewriting
Problem: CDN plugins rewrite URLs in database:
wp_posts table (post content):
<!-- Original -->
<img src="https://yoursite.com/uploads/photo.jpg">
<!-- After CDN activation -->
<img src="https://cdn.yoursite.com/uploads/photo.jpg">
Backup Impact:
- Database contains CDN URLs
- Restoring to new domain keeps old CDN references
- Broken images if CDN subdomain doesn’t exist on new site
Asset Location Confusion
CDN serves files from origin server:
- Files still physically on WordPress server:
/wp-content/uploads/ - CDN caches copies on edge servers
- Backup includes original files (good!)
- But database references CDN URLs (problematic)
Restore Scenario:
Backup from: yoursite.com (using cdn.yoursite.com)
Restore to: newsite.com
Problem: Database has cdn.yoursite.com URLs
Files exist at: newsite.com/wp-content/uploads/
Result: Broken images (looking for cdn.yoursite.com instead of newsite.com)
Cache Invalidation After Restore
Restoring from backup = stale CDN cache:
Example:
- Site has logo-v1.png cached on CDN
- You restore backup from 2 weeks ago with logo-v2.png
- CDN still serves cached logo-v1.png
- Site shows wrong logo until cache expires or manual purge
Backing Up CDN-Enabled Sites
What to Include in Backups
Database:
- Contains CDN-rewritten URLs
- Backup as-is (with CDN URLs)
- Will search-replace during restoration
Files:
/wp-content/uploads/– All media files (CDN source)/wp-content/themes/– Themes (may reference CDN)/wp-content/plugins/– CDN plugins and configurationwp-config.php– May contain CDN constants
CDN Configuration:
- Document CDN provider settings
- Note subdomain/custom domain
- Record CDN zones/distributions
- Save plugin settings (screenshot or export)
Backup Best Practices with CDN
1. Include CDN Plugin Settings:
Many CDN plugins store config in wp_options:
SELECT * FROM wp_options
WHERE option_name LIKE '%cdn%' OR option_name LIKE '%cloudflare%';
Backup includes this automatically.
2. Document CDN Setup:
Create cdn-config.txt with:
CDN Provider: Cloudflare
CDN URL: yoursite.com (proxied)
Plugin: Cloudflare Official Plugin
API Token: [stored in wp_options]
Cache Settings: Browser cache 4 hours, edge cache 30 days
Page Rules: Cache everything on /wp-content/*
Alternative access (if CDN down): origin.yoursite.com
3. Test Backup Without CDN:
Before creating backup:
- Temporarily disable CDN plugin
- Verify site works with local assets
- If yes, CDN is non-essential layer
- Create backup
- Re-enable CDN
This proves backup is self-contained.
Find-Replace Strategies for CDN URLs
Identifying CDN URLs in Backup
Search backup SQL file for CDN patterns:
# Linux/Mac
grep -i "cdn\." backup.sql | head -20
# Windows (PowerShell)
Select-String -Path backup.sql -Pattern "cdn\." | Select-Object -First 20
Common patterns:
cdn.yoursite.comstatic.yoursite.comd3abc123xyz.cloudfront.netyoursite-cdn.stackpathcdn.com
Search-Replace During Restoration
Using WP-CLI:
# Replace CDN subdomain with new domain
wp search-replace 'cdn.oldsite.com' 'newsite.com' --all-tables
# Replace CloudFront URL with new domain
wp search-replace 'd3abc123xyz.cloudfront.net' 'newsite.com' --all-tables
# Replace old domain with new domain (catches non-CDN URLs too)
wp search-replace 'oldsite.com' 'newsite.com' --all-tables
Using Better Search Replace plugin:
- Install Better Search Replace
- Search for:
cdn.oldsite.com - Replace with:
newsite.com - Select all tables
- Run (uncheck “dry run” after testing)
Backup Copilot Pro Find-Replace:
- During restoration, enable “Find & Replace URLs”
- Old URL:
https://cdn.oldsite.com - New URL:
https://newsite.com - Plugin updates all database references automatically
Multiple CDN URL Patterns
Complex scenario: Site uses multiple CDN URLs:
- Images:
cdn.yoursite.com - CSS/JS:
static.yoursite.com - Videos:
d3abc123xyz.cloudfront.net
Solution: Multiple search-replace operations:
wp search-replace 'cdn.yoursite.com' 'newsite.com' --all-tables
wp search-replace 'static.yoursite.com' 'newsite.com' --all-tables
wp search-replace 'd3abc123xyz.cloudfront.net' 'newsite.com' --all-tables
Run sequentially to replace all CDN patterns.
Provider-Specific Backup Considerations
Cloudflare
Unique Characteristics:
- DNS-based proxy (transparent to WordPress)
- URLs don’t change in database (no rewriting!)
- Caches entire site, not just assets
- Page Rules affect dynamic content
Backup Simplicity: Cloudflare is easiest for backups:
- Database has normal URLs (no CDN subdomain)
- Restore to new domain = change WordPress site URL
- No CDN URL find-replace needed
- Just update Cloudflare DNS to point to new server
Post-Restore Steps:
- Restore backup to new server
- Update Cloudflare DNS A record to new server IP
- Purge Cloudflare cache: Performance > Purge Everything
- Test site loads correctly
- Done!
Development Mode:
- Enable Cloudflare > Caching > Development Mode
- Bypasses cache for 3 hours
- Useful when testing restored site
MaxCDN / StackPath
Characteristics:
- Pull CDN with custom subdomain
- Plugin rewrites URLs in database
- Separate CDN zone configuration
Backup Challenge: Database contains yoursite-cdn.stackpathcdn.com URLs.
Restoration Process:
- Restore backup to new site
- Install StackPath plugin
- Create new CDN zone (or keep old one)
- Run search-replace:
- Old:
yoursite-cdn.stackpathcdn.com - New:
newsite.com(if not using CDN) ornewsite-cdn.stackpathcdn.com
- Old:
- Purge StackPath cache from dashboard
Alternative: Keep Same CDN Zone: If migrating to new domain but keeping CDN:
- Update origin server in StackPath dashboard
- Point to new server IP
- Keep CDN URLs unchanged in database
- No search-replace needed
Amazon CloudFront
Characteristics:
- Most complex setup
- Unique distribution URLs (d3abc123xyz.cloudfront.net)
- Requires AWS console management
Backup Challenge: Database full of CloudFront URLs.
Restoration Options:
Option A: Disable CDN on Restored Site
# Replace CloudFront URLs with new domain
wp search-replace 'd3abc123xyz.cloudfront.net' 'newsite.com' --all-tables
Option B: Create New CloudFront Distribution
- Restore backup
- Create new CloudFront distribution pointing to new site
- Get new distribution URL (d3def456abc.cloudfront.net)
- Search-replace old CloudFront → new CloudFront
- Update DNS CNAMEs if using custom domain
Option C: Update Existing Distribution
- Restore backup to new server
- Update CloudFront origin to point to new server
- Keep distribution URL unchanged
- No database search-replace needed
- Invalidate CloudFront cache
Restoring Sites with Active CDN
Pre-Restoration Checklist
1. Document Current CDN Setup:
- Provider name
- CDN URLs/subdomains
- Plugin settings
- DNS records (CNAME)
2. Decide CDN Strategy for Restored Site:
- Keep CDN active?
- Disable temporarily?
- Migrate to new CDN?
3. Prepare Search-Replace Plan:
- List all CDN URLs in database
- Determine replacement URLs
- Test find-replace on staging first
Step-by-Step Restoration Process
Scenario: Restoring to new domain with CDN disabled
- Restore Database:
- Import backup SQL to new database
- Database contains old domain + CDN URLs
- Restore Files:
- Extract wp-content, wp-config.php
- Files uploaded to new server
- Update wp-config.php:
- Update database credentials for new database
- Search-Replace URLs:
# Replace old domain (non-CDN)
wp search-replace 'oldsite.com' 'newsite.com' --all-tables
# Replace CDN subdomain
wp search-replace 'cdn.oldsite.com' 'newsite.com' --all-tables
- Deactivate CDN Plugin:
wp plugin deactivate cdn-enabler
- Verify Assets Load:
- Visit site, check images display
- Inspect source code for CDN URLs
- Should all be newsite.com
- Test Functionality:
- Forms submit
- Pages load
- Admin panel works
Scenario: Restoring with CDN active
- Restore database and files (same as above)
- Keep CDN plugin active
- Update CDN configuration in plugin settings:
- CDN URL: Update to new CDN subdomain or keep old
- Origin: Update to new server
- Update CDN provider dashboard:
- Point origin to new server IP
- Purge CDN cache
- Test site loads with CDN serving assets
Troubleshooting CDN Backup Issues
Broken Assets After Restoration
Symptom:
- Site loads but images show broken
- CSS/JS not loading
- Mixed content warnings
Diagnosis: View page source, check image URLs:
<!-- Problem: Still referencing old CDN -->
<img src="https://cdn.oldsite.com/uploads/image.jpg">
Solution: Run search-replace to fix CDN URLs:
wp search-replace 'cdn.oldsite.com' 'newsite.com' --all-tables --dry-run
# Review output, then run without --dry-run
wp search-replace 'cdn.oldsite.com' 'newsite.com' --all-tables
Verify:
- Refresh page with cache cleared (Ctrl+Shift+R)
- Check source again
- Images should now load from newsite.com
Mixed Content Warnings (HTTP/HTTPS)
Problem:
- Restored site uses HTTPS (SSL)
- CDN URLs in database use HTTP
- Browser blocks HTTP content on HTTPS page
Example:
<!-- Page is HTTPS -->
<html>
<!-- Image is HTTP - blocked! -->
<img src="http://cdn.oldsite.com/uploads/photo.jpg">
Solution: Replace HTTP CDN URLs with HTTPS:
wp search-replace 'http://cdn.oldsite.com' 'https://newsite.com' --all-tables
Or use Really Simple SSL plugin to automatically convert.
CDN Cache Shows Old Content
Problem:
- Site restored from backup
- Old content still showing (from CDN cache)
Solution: Purge CDN cache:
Cloudflare:
- Cloudflare dashboard
- Caching > Purge Cache > Purge Everything
StackPath:
- StackPath dashboard
- Sites > yoursite > Purge
- Purge All
CloudFront:
aws cloudfront create-invalidation \
--distribution-id EDFDVBD6EXAMPLE \
--paths "/*"
Or via AWS Console > CloudFront > Invalidations
After purging:
- Wait 5-10 minutes for purge to complete
- Clear browser cache
- Reload site
- Should show current content
CDN Subdomain DNS Not Resolving
Problem:
- Restored site references cdn.newsite.com
- DNS not configured for CDN subdomain
- Assets fail to load
Solution: Create DNS CNAME record:
Type: CNAME
Name: cdn
Value: newsite.com (or CDN provider URL)
TTL: 300
Or point directly to CDN provider:
Type: CNAME
Name: cdn
Value: newsite-cdn.stackpathcdn.com
Allow 5-60 minutes for DNS propagation.
Testing Backups with CDN Active
Staging Environment Setup
Best Practice: Test restores on staging subdomain
- Create staging subdomain:
- staging.yoursite.com
- Separate from production
- Restore backup to staging:
- Import database
- Upload files
- Update URLs for staging:
wp search-replace 'yoursite.com' 'staging.yoursite.com' --all-tables
wp search-replace 'cdn.yoursite.com' 'staging.yoursite.com' --all-tables
- Disable CDN on staging:
wp plugin deactivate cdn-enabler cloudflare
- Test restoration:
- Site loads correctly
- All content accessible
- No broken assets
- Document process:
- Note any issues encountered
- Refine restoration procedure
- Update disaster recovery plan
Automated Testing
WP-CLI script to test backup restoration:
#!/bin/bash
# backup-test.sh
# Variables
BACKUP_SQL="backup.sql"
BACKUP_ZIP="backup.zip"
DB_NAME="staging_db"
# Import database
wp db import $BACKUP_SQL --path=/var/www/staging
# Extract files
unzip -o $BACKUP_ZIP -d /var/www/staging/wp-content
# Search-replace URLs
wp search-replace 'yoursite.com' 'staging.yoursite.com' --all-tables --path=/var/www/staging
wp search-replace 'cdn.yoursite.com' 'staging.yoursite.com' --all-tables --path=/var/www/staging
# Verify site loads
curl -I https://staging.yoursite.com | grep "200 OK"
if [ $? -eq 0 ]; then
echo "Backup restoration test: SUCCESS"
else
echo "Backup restoration test: FAILED"
exit 1
fi
Run monthly to verify backups are restorable.
Performance Optimization
Backup Speed with CDN
CDN doesn’t affect backup speed:
- Backups copy local files (not from CDN)
- Database contains CDN URLs (text, minimal size impact)
- Backup time same whether CDN active or not
CDN helps with backup downloads: If serving backup files via WordPress:
- Enable CDN caching for backup directory
- Users download from CDN edge servers
- Faster download speeds globally
Not recommended for security: Backups should be private, not CDN-cached.
Restore Speed Optimization
Disable CDN during restoration:
- Eliminates cache invalidation delays
- Immediate visibility of restored content
- Re-enable CDN after verification
Purge cache strategically: Instead of “Purge Everything,” purge specific paths:
/wp-content/uploads/*
/wp-content/themes/*
/wp-content/plugins/*
Preserves cache for unchanged content.
Best Practices Summary
Before Enabling CDN:
- Create baseline backup without CDN
- Document URLs before rewriting
With CDN Active:
- Backup regularly (CDN doesn’t eliminate need)
- Document CDN configuration
- Test restores on staging with CDN disabled
During Migration:
- Plan search-replace strategy
- Test on staging first
- Purge CDN cache after restoration
Ongoing:
- Monitor backup completion (CDN shouldn’t interfere)
- Update disaster recovery documentation with CDN steps
- Test restoration annually
Related Resources
- Cloudflare WordPress Guide
- CDN Best Practices
- WordPress CDN Integration
- Amazon CloudFront Documentation
- CDN Performance Optimization
Running a CDN? Backup Copilot Pro handles CDN URLs automatically with smart find-replace. Backup and restore seamlessly, regardless of your CDN setup—try it free!

