How to Recover from WordPress Page Load Failures After an AWS Public/or Elastic IP Change

So over the past week, I decided to spin up a new AWS instance to host this blog on.  My primary objective was to obtain a possible minor gain in performance by migrating from Apache to NGINX.  I exported my site from WordPress using the native export feature visible in the screenshot below.  I made a selection of ‘All content’ to get everything.

Wordpress Export Setting - calvintrobinson.com

WordPress Export Setting – calvintrobinson.com

Next, I launched a new instance, installed NGINX, MYSQL, PHP, WordPress, etc. and performed an import of my exported WordPress file into the new deployment.  I performed the configuration of plugins and appearance settings as necessary.  All the while, this was done by accessing the web admin portal over its assigned public Amazon IP.  This key piece of information is relevant to the issue we’ll uncover further in just a moment.

Once I was done with the configuration, I accessed the site, looked it over and determined that the DNS cutover was ready.  I requested a new Elastic IP targeted to my VPC be allocated from EC2.  I associated this EIP to my instance and then updated the A record in DNS to reflect the new IP.  At this point, I’m thinking I’ll be able to navigate to the URL and see my blog pop up right?  No…

Instead what I saw was a broken index page that was excrutiatingly slow to load and void of images.  I investigated the usual suspects, security group, IP tables, some service not started, etc.  It then dawned on me after some thinking that the IP change was most certainly to blame and that I needed someway to update any references to the old IP.

It was at this point that I discovered the solution on WordPress.org which turned out to be a rather simple fix.  It turns out that the IP address the site was accessed by is retained in the database and config files presumably as well.  This must be updated to reflect the DNS name that should be used.  In order to make this update, I needed to SSH to my instance and modify the functions.php file using a text editor.  In this file, I needed to add the following lines near the top of the file:

Add this code to your functions.php file – Please change the domain name, do not use calvintrobinson.com  =)

As instructed by the WordPress.org tutorial, if you make this modification to your functions.php file, you should remove the lines after the fix is proven to be successful.  Apparently, the change they make is persistent and they don’t need to remain in the file.  At this point, I noticed that my page was once again accessible.

Disclaimer:  Please ensure you have adequate backups available before making any changes to your site.  I will not be held responsible for issues that may arise from using this code.  It is recommended that you visit the WordPress.org site for more information.




  1. The next time that you try to load the plugins page in WordPress, it ll not be able to locate the plugins folder and de-activate all plugins. Once the plugin with the issue is located, you can choose to remove it or check the plugins homepage for updates.

Leave a Reply

Your email address will not be published. Required fields are marked *