How to convert a non-WWW WordPress site to WWW

UPDATE (Jun 6, 2019): Converting this site from non-WWW to WWW created a significant caching issue with WP-Rocket.

Namely, WP-Rocket had created a cached version of the non-WWW homepage, and this version remained inside the /wp-content/cache/ directory even after the conversion. This version continued to exist despite clearing the cache from the WP-Rocket settings.

Since the non-WWW cached version of the homepage referenced non-WWW images, it displayed blank areas instead of WWW images.

It was this cached version that Googlebot continued to crawl, and for several months Google displayed this outdated & faulty version in its index. (ie: Google continued to index the non-WWW homepage version instead of the WWW version, its cached version did not display any images, and styles for the social media buttons were broken for mobile phones.)

Deleting old cache files & folders from the /wp-content/cache/ folder on the server solved this problem immediately.

UPDATE (Dec 30, 2018): This site’s SEO took a big hit following the conversion from non-WWW to WWW. Therefore, conversion to WWW is not recommended unless absolutely required for using a content delivery network.

Ancient Greek Keyboard’s original domain URL was https://www.ancientgreekkeyboard.com, but was recently changed to https://www.ancientgreekkeyboard.com.

While using WWW in the domain name is said to result in slight improvements in site speed, security and scalability, the main reason for the change was so that a content delivery network could be used in the future (CDNs typically require sites to use WWW in their domain names).

The following procedure was used in converting this WordPress site from non-WWW to WWW:

Use the Duplicator plugin to create a backup of the current site.
Download the backup created by Duplicator to the local computer (and download the corresponding INSTALLER.PHP file as well).
Download the current HTACCESS file at the root of the WordPress installation using Filezilla. Save a copy in a secure location on the local computer.
Comment out all HTTPS redirection code in the HTACCESS file.
Upload the edited HTACCESS file back to the root of the WordPress installation on the server.
Download the WP-CONFIG.PHP file from the root of the WordPress installation on the server.
Comment out:
define('WP_HOME', 'https://www.ancientgreekkeyboard.com');
and:
define('WP_SITEURL', 'https://www.ancientgreekkeyboard.com');
(If these statements are nowhere to be found in WP-CONFIG.PHP, then ignore this step.)
Save WP-CONFIG.PHP file & upload it to the root of the WordPress installation on the server. (If the previous step was skipped, this step can be skipped as well.)
On the WordPress administration page, go to: Settings > General.
WordPress Address (URL) set to https://www.ancientgreekkeyboard.com.
Site Address (URL) set to https://www.ancientgreekkeyboard.com
Click the Save button.
Automatically logged out of the WordPress administration page.
Log back into the WordPress administration page.
Check Settings > Permalinks to verify all permalinks include WWW. (They did.)
Add & activate the Velvet Blues Update URLs plugin.
Click the Update URLs link on the WordPress administration plugin page.
Input Old URL: https://www.ancientgreekkeyboard.com
Input New URL: https://www.ancientgreekkeyboard.com
Click all checkboxes for updating URLs (except GUIDs).
Click the Update URLs NOW button.
Velvet Blues updated 131 content items, 19 attachments, and 34 custom fields.
Also used Velvet Blues to update from HTTP to HTTP://WWW (ie: from https://www.ancientgreekkeyboard.com to https://www.ancientgreekkeyboard.com.) Two content items were thus updated. (This was unexpected, since I believed there were no HTTP URLs residing on the site.)
Deactivate the Velvet Blues Update URLs plugin.
Change WP-CONFIG.PHP to reflect the new WWW domain name:
define('WP_HOME', 'https://www.ancientgreekkeyboard.com');
define('WP_SITEURL', 'https://www.ancientgreekkeyboard.com');
Change the salts in WP-CONFIG.PHP.
Upload WP-CONFIG.PHP to the root directory of the WordPress installation.
Automatically logged out of the WordPress administration panel.
Log back into the WordPress administration page.
Change the HTACCESS code in the root of the WordPress installation to automatically redirect URLs to HTTPS://WWW.
### First rewrite any request to the wrong domain to use the correct one (here www.) RewriteCond %{HTTP_HOST} !^www\. RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ### Now, rewrite to HTTPS: RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Update URL addresses in HTACCESS to refer to WWW.
Save HTACCESS & upload to root directory of the WordPress Installation on the server.
In the Child Theme folder, find the STYLE.CSS, STYLE-LOGIN.CSS, and FUNCTIONS.PHP files and change all references from non-WWW to WWW. (NOTE: If the latter two files don’t exist, then just update the STYLE.CSS file.)
Save these three files & upload them to the Child Theme folder on the server. (Again, don’t bother with STYLE-LOGIN.CSS and /or FUNCTIONS.PHP if they don’t exist!)
Check a few images in the Media Library to verify that the images now have the correct WWW URL.
Check a few Pages & Posts that they have WWW URLs.
If using a shopping cart plugin, go to the settings & change all URLs to include WWW.
Change all URLs to WWW in whatever SEO plugin is being used.
The Guest custom avatar was somehow reset to default settings during the entire process. Go to Settings > Discussion to set it correctly again.
Clear the WP-Rocket cache (or the cache for whatever caching plugin you’re using, if any).
On Google Webmaster Tools, delete the current non-WWW property. Add a new WWW property, verify it, and add a sitemap.
Repeated the previous step for Bing Webmaster Tools.
Updated references to WWW in the ROBOTS.TXT file, and uploaded to the server.

Other posts in this series: