How to migrate a WordPress site from HTTP to HTTPS without downtime

Migrating your WordPress site to HTTPS is essential for SEO, speed, and trust—but doing it wrong can break your site or affect your rankings.

Here’s a zero-downtime migration strategy used across enterprise and publisher sites we’ve worked with. Follow these steps to upgrade to HTTPS safely, without disrupting your live environment.

Step 1: Set up a staging environment

Modifying a live production server directly during an HTTPS migration poses a high risk. Instead, create a staging environment – a complete replica of your production site – for a zero-downtime transition. Here’s why:

• Perform thorough testing: A staging environment lets you install your SSL certificate, configure redirects, and troubleshoot mixed content issues without affecting your live site.
• Implement iterative and controlled changes: By making a series of smaller, testable changes, you minimize the risk of unexpected problems.
• Ensure an easy and reliable rollback: If unforeseen issues occur, revert to a known good state in staging, keeping your live site operational.

Tip: Do not assume your staging environment perfectly mirrors production. Verify its integrity before starting. Perform a full data comparison to ensure 100% parity between staging and production.

Step 2: Obtain and install your SSL certificate (on staging!)

Before anything else, secure your SSL certificate. The process varies depending on your hosting provider, but generally involves three steps to set up ssl certificate on WordPress​:

1. Generate a CSR (Certificate Signing Request)

Your hosting provider will typically provide tools or instructions for generating a CSR within your control panel.  The CSR contains information about your domain and organization, and it includes the public key that will be associated with your certificate. A private key is also generated during this process, keep this private key secure, as you’ll need it for installation.

2. Purchase or obtain an SSL certificate

You have several options

Hosting provider

Many WordPress hosting companies offer SSL certificates as part of their service, often with a simplified installation process.  Check your hosting provider’s documentation for details.

Certificate Authority (CA)

If your hosting doesn’t offer certificates, you can purchase one directly from a CA like GoDaddy, GlobalSign, or Comodo. CAs offer various certificate types, including:

• Domain Validation (DV): The quickest and most common type. Validation usually involves proving control over the domain, which can be done via email validation, file-based validation (uploading a specific file to your website), or DNS-based validation.
• Organization Validation (OV): Requires more rigorous verification of your organization’s identity.
• Extended Validation (EV): The highest level of validation, providing the most trust indicators in the browser.

Let’s Encrypt

Let’s Encrypt provides free SSL certificates and is a popular option for many sites. You can use certbot to get a Let’s Encrypt certificate.

• HTTP-01 Challenge: Let’s Encrypt provides a token, and you place a file containing that token on your web server under a specific path (/.well-known/acme-challenge/). Let’s Encrypt then checks for that file via an HTTP request to verify domain control.
• DNS-01 Challenge: Let’s Encrypt provides a token, and you create a specific TXT record in your domain’s DNS settings containing that token. Let’s Encrypt then queries your DNS records to verify domain control. This method is useful if you can’t easily modify your web server’s files or if you need a wildcard certificate.

For EasyEngine Users, obtaining and installing a Let’s Encrypt certificate is simplified to a single command:

ee site update example.com --ssl=le 

(Replace `example.com` with your actual domain name.)

DNS-Based Validation and Propagation

When using DNS-based validation (for DV certificates or Let’s Encrypt’s DNS-01 challenge or wildcard certificate/DNS based certificate in EasyEngine), you’ll need to add a specific TXT record to your domain’s DNS settings. After adding the record, it can take some time for the change to propagate across the internet. This is known as DNS propagation. While propagation is often relatively fast (minutes to a few hours), it can sometimes take up to 24-48 hours. During this time, the certificate authority might not be able to verify your domain control, delaying certificate issuance.

3. Install the certificate

Follow your hosting provider’s specific instructions or, if you purchased from a CA, their provided documentation. This usually involves:

• Uploading files: If you’re using a manual process, you’ll likely need to download the SSL certificate and any intermediate certificate bundle files (often .crt or .pem files) from your CA and upload them to your server.
• Control panel: Pasting the certificate contents into a designated field within your hosting control panel.
• Command line: Using a command-line tool like OpenSSL.
• EasyEngine: You do not need to do anything extra, the site update command has taken care of issuing, installing and setting up the certificate.

Step 3: Configure WordPress using wp-config.php

While plugins are available to manage the transition to HTTPS, for better control and to minimize potential plugin conflicts or overhead, we recommend directly modifying the wp-config.php file. This approach provides granular control and reduces dependencies. Remember to perform these steps on your staging environment.

Here’s the recommended procedure:

1. Connect to your server: Use SSH or SFTP to access your server files.
2. Locate wp-config.php: This file is generally located in the root directory of your WordPress installation or one level above the root directory.
3. Edit wp-config.php: Open the file with a text editor.  Add the following lines above the /* That's all, stop editing! Happy blogging. */ line:

define('WP_HOME','https://your-domain.com');
define('WP_SITEURL','https://your-domain.com');

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

Replace your-domain.com with your actual staging domain name.

• WP_HOME and WP_SITEURL: These constants force WordPress to use HTTPS for all generated URLs. This is a critical step in preventing mixed content issues.
• HTTP_X_FORWARDED_PROTO: This directive is essential if your site is behind a load balancer or proxy server that handles SSL termination. It ensures WordPress correctly detects HTTPS even if the direct connection to the WordPress application server is HTTP.
• Verify HTTPS configuration: After updating the wp-config.php, thoroughly test your staging site and verify the HTTPS configuration using an online SSL checker like SSL Labs. This will confirm that the SSL certificate is correctly installed and that your site is serving content securely over HTTPS. This proactive check identifies potential issues before they affect your live site.

Step 4: Database updates: replacing HTTP with HTTPS

Even after configuring wp-config.php, your WordPress database will likely contain hardcoded HTTP URLs within post content, image URLs, and other data.  These URLs need to be systematically replaced with their HTTPS equivalents. Always perform these steps on your staging environment first.

Back up your database before proceeding!

Before making any changes to your database, creating a backup is absolutely essential. This ensures you have a restore point in case of unexpected issues. You have several options for backing up your staging database:

• Hosting provider tools: Many hosting providers offer built-in backup and restore functionality, often accessible through their control panel. This is usually the easiest and most reliable option.
• WP-CLI: If you’re comfortable using the command line, WP-CLI provides a fast and efficient way to export your database:

wp db export backup.sql 

This command will create a SQL file (backup.sql in this example) containing your entire staging database. You can then use wp db import to restore the database if needed.

• WordPress plugins: Plugins like WP Migrate DB or UpdraftPlus which can create database backups. These are convenient, but may have limitations on large sites due to timeouts or memory restrictions.

Choose the method that best suits your technical expertise and your hosting environment. The most important thing is to have a verified, restorable backup before proceeding with the database updates.

Database search and replace (recommended method: WP-CLI)

For large databases or for greater control and reliability, we strongly recommend using the WP-CLI command-line tool:

wp search-replace 'http://your-staging-domain.com' 'https://your-staging-domain.com' --dry-run --report-changed-only --skip-columns=guid

• --dry-run: This performs a test run without making any actual changes. Carefully review the output to ensure that only the intended URLs are being targeted.
• --report-changed-only: This option, used in conjunction with –dry-run, significantly reduces the output by only showing the rows that would be changed. This makes it much easier to review the potential impact.
• --skip-columns=guid: This crucial flag prevents accidental modification of GUIDs (Globally Unique Identifiers), which are used by WordPress for various purposes, including RSS feeds. However if you are making the site live for the first time or migrating to a New Domain you must update the GUIDs to reflect the new domain.

Execute the replacement

Once you’ve verified the dry-run output and are confident in the changes, remove the –dry-run flag and execute the command:

wp search-replace 'http://your-staging-domain.com' 'https://your-staging-domain.com' --skip-columns=guid --report-changed-only

Note: If you removed --skip-columns=guid during the dry run, remove it here as well.

Alternative (for smaller sites or without WP-CLI access)

If you’re working with a smaller site or don’t have access to WP-CLI, you can use a WordPress plugin like Better Search Replace. Always back up your database before using any search and replace plugin.

Step 5: Implementing redirects to force HTTPS connections

Even after configuring WordPress for HTTPS, some requests might still attempt to access your site via HTTP. To ensure all traffic uses HTTPS, we need to implement 301 redirects. The method for doing this depends on your web server software: Nginx or Apache. Always implement these changes on your staging environment first.

1. Nginx configuration

If your site is running on an Nginx web server, you’ll need to modify your Nginx configuration file (usually located at /etc/nginx/sites-available/your-site or /etc/nginx/conf.d/your-site.conf).  Add a new server block to redirect HTTP traffic to HTTPS:

server {
    listen 80;
    server_name your-domain.com www.your-domain.com;
    return 301 https://$host$request_uri;
}

# Existing HTTPS server block
server {
    listen 443 ssl;
    server_name your-domain.com www.your-domain.com;
 #... rest of your HTTPS configuration ...
}

• listen 80;: This tells Nginx to listen for connections on port 80 (the standard HTTP port).
• server_name your-domain.com www.your-domain.com;: Replace this with your actual domain name (and www subdomain, if applicable).
• return 301 https://$host$request_uri;: This is the core redirect rule. It tells Nginx to return a 301 (permanent) redirect to the HTTPS version of the requested URL. $host will be the domain and $request_uri will be the specific page.

sudo nginx -t # Test the configuration for syntax errors
sudo systemctl reload nginx

# Alternatively, if you’re not using systemctl:
sudo service nginx restart

2. Apache configuration (.htaccess)

If your site is running on an Apache web server, you’ll need to modify your .htaccess file:

1. Edit your .htaccess file: This file is located in the root of your WordPress installation.
2. Add the following code above any existing WordPress rules:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule> 

This code checks if the connection is not HTTPS (%{HTTPS} off) and, if so, redirects it to the HTTPS version using a 301 (permanent) redirect.

3. WordPress plugin (simplified approach)

If you’re not comfortable modifying server configuration files, or if you prefer a simpler approach, you can use a WordPress plugin to handle the HTTP to HTTPS redirection. A popular and reliable option is Really Simple Security formerly know as Really Simple SSL.

Install and activate the Really Simple Security plugin from the WordPress plugin directory. It has option for 301 redirect via PHP or .htaccess.

Caution: While plugins simplify the process, they can add overhead and might not be as efficient as server-level redirects (Nginx or Apache).

Why 301 Redirects? 301 redirects are crucial for SEO. They inform search engines that the page has permanently moved to the HTTPS URL, preserving your existing search engine rankings and ensuring that users are directed to the secure version of your site.

Step 6: Fixing mixed content issues on WordPress

Mixed content occurs when your HTTPS page loads resources (images, scripts, stylesheets) over HTTP.  Browsers will flag this as insecure, and some resources might not load at all. Below step shows how to fix mixed content in WordPress​.

Finding mixed content in WordPress

• Browser developer tools:  Use the “Network” tab to identify resources loaded over HTTP.
• Online tools:  Services like Why No Padlock? can scan your staging site for mixed content.

Fixing mixed content in WordPress without plugin

• Update URLs in your database (Step 3 should have caught most of these).
• Check your theme and plugin files:  Look for hardcoded HTTP URLs and update them to HTTPS.

Using a plugin (as a last resort):  Plugins like Really Simple Security can help, but they might not catch everything, and they can add overhead. We prefer manual fixes for better control.

Step 7: Testing, deployment, and post-migration monitoring

Once you’ve completed the previous steps (SSL certificate installation, WordPress configuration, database updates, and redirect implementation), thoroughly tested your staging site, and confirmed that everything is working correctly with a green padlock in the browser address bar, you can remove the WP_HOME and WP_SITEURL constants that were temporarily added to your wp-config.php file in Step 2. Remove (or comment out) the following lines:

define('WP_HOME','https://your-domain.com');
define('WP_SITEURL','https://your-domain.com'); 

Why remove these constants?

While these constants are useful for forcing HTTPS during the migration process, they are generally not recommended for long-term use. WordPress can usually determine the correct site URL automatically. Removing these constants after the migration ensures greater flexibility and avoids potential issues if your site’s URL structure changes in the future. If, at some point, the database values for siteurl and home are changed, and these constants are present, the constants will take precedence. This can cause the site to be inaccessible until the constants are removed.

Comprehensive staging site testing

Before deploying to your live site, thoroughly test every aspect of your staging environment. This includes:

• Visual inspection: Check all pages, posts, and custom post types for correct display and functionality.
• Form submissions: Test all forms (contact forms, login forms, comment forms, etc.) to ensure they work correctly over HTTPS.
• Interactive elements: Verify that all JavaScript-based features, AJAX calls, and other interactive elements function as expected.
• SSL Certificate and mixed content: Use browser developer tools and online checkers (like SSL Labs and Why No Padlock?) to confirm that there are no SSL errors or mixed content issues.
• Redirection check: Check if redirects are properly working.

Back up your live database

Once you’re 100% confident in your staging environment, create a full backup of your live database. This is a critical safety measure before making any changes to your production site.

Replicate changes on your live server

Carefully replicate all the changes you made on your staging environment to your live server, from step 1 to step 5.

Update your CDN (if applicable)

If you’re using a Content Delivery Network (CDN), you’ll need to update its configuration to ensure it serves content over HTTPS. The specific steps will vary depending on your CDN provider, but generally involve:

• Enabling HTTPS: Ensure HTTPS is enabled for your CDN distribution.
• Updating origin settings: Update your CDN’s origin settings to point to your HTTPS-enabled live site.
• Purging cache: Purge the CDN’s cache to ensure it serves the latest HTTPS versions of your assets. This is crucial to avoid mixed content issues.
• Refer to your CDN provider’s documentation for detailed instructions.

Post-migration monitoring

After deploying the changes to your live site, closely monitor its performance and functionality. Use monitoring tools such as:

• Uptime monitoring: Services like UptimeRobot, Pingdom, or New Relic can alert you to any downtime or availability issues.
• Error log monitoring: Regularly check your server’s error logs for any PHP errors, database errors, or other issues.

Ensure a successful HTTPS migration

Migrating to HTTPS is essential for every WordPress site, providing critical security, SEO benefits, and enhanced user trust. By following a methodical, staging-based approach, you can ensure a smooth, hiccup-free, and zero-downtime transition. Thorough testing and a reliable rollback plan are crucial. Remember, this isn’t just about the green padlock, it’s about protecting your data and building confidence with your users.

If you need expert assistance, rtCamp’s team has extensive experience in managing successful WordPress migrations. Contact us for a secure and seamless transition.