Migrate 3 WordPress Sites to Subdomains on One Server

This guide walks you through moving three existing WordPress sites onto a single server, each accessible via its own subdomain (e.g., site1.example.com, site2.example.com, site3.example.com). You’ll keep all content, themes, plugins, and media intact, with minimal downtime. Before starting, ensure you have: full backups of all three sites (files and database), SSH or cPanel access to the destination server, and the ability to create DNS records for your domains.

What You’ll Need

• Full backups of each WordPress site (files and database export).
• Access to the destination server (SSH, cPanel, or equivalent).
• Ability to edit DNS records for each domain.
• A text editor for configuration files.
• Patience and a checklist to avoid mix-ups.

Step-by-Step

1. Plan the subdomains. Decide on the subdomain for each site (e.g., store.example.com, blog.example.com, forum.example.com). Ensure they don’t conflict with existing records.
2. Create DNS records. For each subdomain, add an A record pointing to your server’s IP address. If you’re using a wildcard, you can skip this, but explicit records are safer. Wait for DNS propagation (can take minutes to hours).
3. Prepare the server. Ensure your web server (Apache, Nginx, LiteSpeed) is installed and running. Create a directory structure, e.g., /var/www/subdomain1, /var/www/subdomain2, /var/www/subdomain3.
4. Create databases. For each site, create a MySQL/MariaDB database and a user with all privileges on that database. Note the database name, user, and password for each.
5. Upload files. Upload the WordPress files for each site to its respective directory. You can use FTP, SFTP, or SCP. Ensure file permissions are correct (directories 755, files 644).
6. Import databases. Import each site’s database backup into its new database. Use phpMyAdmin, the mysql command line, or a tool like WP-CLI.
7. Configure web server virtual hosts. Create a virtual host (Apache) or server block (Nginx) for each subdomain. Point the document root to the correct directory. Include PHP handling (e.g., via FastCGI). Enable the sites and reload the web server.
8. Update wp-config.php. For each site, edit the wp-config.php file to use the new database credentials. Look for DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST (usually localhost).
9. Update the site URL in the database. This is critical. Use WP-CLI or phpMyAdmin to run SQL queries. For each site, execute:
   UPDATE wp_options SET option_value = 'http://subdomain.example.com' WHERE option_name IN ('siteurl', 'home');
   Replace http://subdomain.example.com with your actual subdomain. If you used a different table prefix, adjust wp_ accordingly.
10. Update any hardcoded URLs. Search the database for the old domain and replace with the new subdomain. Use a plugin like “Better Search Replace” or run SQL queries. Be careful with serialized data; a plugin is safer.
11. Update .htaccess (Apache) or Nginx rules. If you use permalinks, ensure the rewrite rules are correct. For Apache, the .htaccess file should be present; for Nginx, add the standard WordPress rewrite rules to the server block.
12. Test each site. Visit each subdomain in a browser. Check the homepage, a post, and the admin login. Look for mixed content warnings (http vs https) if you’re using SSL.
13. Set up SSL certificates. If you haven’t already, install Let’s Encrypt certificates for each subdomain. Use a tool like Certbot. After installation, update the site URLs to use https instead of http (repeat step 9 with https).
14. Update DNS and go live. Once everything works, update the DNS records if you had set them to a temporary IP. Remove any maintenance mode or redirects.
15. Final checks. Verify that all plugins and themes work, and that media files load correctly. Check the database collation and table prefixes are consistent.

Common Mistakes

• Forgetting to update the site URL. This is the most common cause of a broken site after migration. Always update siteurl and home in the database.
• Using the same database for multiple sites. Each site must have its own database, or at least a unique table prefix, to avoid conflicts.
• Incorrect file permissions. If WordPress can’t write to files, you’ll see errors. Set directories to 755 and files to 644, and ensure the web server user owns them.
• Not updating .htaccess. If permalinks break, you’ll get 404 errors. Ensure the rewrite rules are present.
• Hardcoded URLs in content. Images and links may still point to the old domain. Use a search-replace tool to update them.
• Ignoring mixed content. If you switch to https, some resources may still load via http, causing warnings. Use a plugin to fix or update URLs.

Tips

• Use WP-CLI. It can speed up database updates and file operations. For example: wp search-replace 'old.com' 'new.com' --all-tables.
• Take a fresh backup before starting. Keep it on a separate machine, not the server.
• Test on a staging subdomain first. If possible, migrate one site to a test subdomain, verify, then repeat for the others.
• Use a plugin for search-replace. Plugins like “Better Search Replace” handle serialized data correctly, which manual SQL might break.
• Keep a log of all changes. Note database names, users, and paths for each site to avoid confusion.
• If using a CDN, purge its cache. Otherwise, old URLs may be served.

Troubleshooting

• Site shows “Error establishing a database connection”. Check wp-config.php for correct database name, user, password, and host. Ensure the database exists and the user has privileges.
• Redirect loop or wrong URL. This usually means the site URL is still set to the old domain. Double-check the wp_options table. Also check for any redirect rules in .htaccess or Nginx config.
• 404 errors on pages. Permalinks are broken. Go to Settings > Permalinks and click “Save Changes” to flush rewrite rules. If that doesn’t work, check the .htaccess file (Apache) or Nginx rewrite rules.
• Mixed content warnings. Some resources load via http. Use a plugin like “Really Simple SSL” or manually replace URLs. Also update the site URL to https.
• Cannot log in to admin. If you’re locked out, use WP-CLI to reset the password: wp user update <user> --user_pass=NEWPASS. Or directly edit the database.
• Images missing. The media URLs are still pointing to the old domain. Run a search-replace for the old domain in the wp_posts and wp_postmeta tables.
• Subdomain not resolving. Check DNS propagation using a tool like dnschecker.org. Ensure the A record points to the correct IP. Also check the server’s virtual host config for typos.
• PHP errors. Enable error reporting in wp-config.php (define(‘WP_DEBUG’, true);) to see the exact issue. Common causes are missing PHP extensions or incorrect file permissions.

Frequently Asked Questions

• Do I need to move the files, or can I copy them? Copying is fine, but ensure the destination directory is empty and permissions are correct. Moving is safer to avoid duplication.
• Can I use the same database for all three sites? Yes, but you must use a different table prefix for each (e.g., wp_site1_, wp_site2_). However, it’s simpler and safer to use separate databases.
• What if my site uses a custom domain instead of a subdomain? The process is the same; just point the domain to the server and set the site URL accordingly. You can use both a subdomain and a custom domain if needed.
• Will my SEO be affected? If you set up proper redirects from old URLs to new ones, SEO impact is minimal. Use 301 redirects for any old URLs that change.
• How long does the migration take? For three small sites, it can take 2-4 hours, including DNS propagation. Larger sites or slow connections may take longer.
• Do I need to update the .htaccess file manually? Usually not, but if permalinks are broken, you may need to add the standard WordPress rewrite rules. In most cases, visiting Settings > Permalinks and saving will regenerate it.

Related

• Can’t Access WordPress Admin After Enabling HTTPS? Fix
• WordPress Migration Problems and Fixes
• Duplicate a Post and Publish the Edited Copy?