Support

The URL of the site you are restoring to contains a part of the URL path of the site you backed up from. This will cause your restored site to fail.

For example, let's say the original site's URL was http://localhost/foo. Note the foo bit? This is the URL path of the site you are backing up from.

If you try to restore this to https://foo.example.com, https://foobar.example.com, or even https://foo.com or https://foobar.com the restored site will fail. As you can see all these URLs have foo (whole or partial) in the domain or subdomain of the site we are restoring to.

Because both original (backed up from) and restoration (restoring to) URLs contain the common text foo the replacement of URLs and relative paths inside your site's database contents and .htaccess files will get mixed up. This will cause your restored site to be broken and unusable.

This is not something that can be worked around automatically. WordPress is storing both absolute and relative URLs. In the case of relative URLs in our example, they are expressed by WordPress similar to /foo/something. Since the restored site is in a different path (in our example that's / i.e. the domain's root) we need to replace /foo with /. However, this would also replace it in https://foo.example.com turning it into https://.example.com. Whoops! Now that link is broken!

You might think that's silly. Clearly, the https://foo.example.com URL is something that came from another replacement during restoration. Obviously running more replacements on top of what we have already replaced is wrong. Unfortunately, computers can't "mark" replaced text in any way, at least not without going into very complicated code which would have caused the data replacement to take so long that most servers would fail even for the tiniest sites. The only thing we can reasonably do is run all the replacements against the same content one after another. This is what is breaking the restored site.

How to best address this problem

It is recommended that you first try to restore to a location that does not share the same text in any part of its URL as the intended destination. Then you can back up this temporary restored site. Finally, you can restore that new backup to the intended destination.

In our example, we can take a backup from http://localhost/foo and restore it to http://localhost/temp123. Since foo and temp123 are very different we do not risk any issues with URL replacements. The restored site works.

Then, we can take a backup from http://localhost/temp123 and restore it to https://foo.example.com. Again, temp123 and foo.example.com are very different, therefore we do not risk any issues with URL replacements. The restored site works.

A quicker way to address this problem

During restoration you end up in the Data Replacement page. There you can see all the replacements which will take place. Find all the replacements with just the path of the site and append a forward slash to them.

For example, replace FROM /foo TO / should become replace FROM /foo/ (notice the trailing slash) TO /.

In most cases this works without having to do a double restoration.