I’ve managed to get my Sitely site running. the export process was remarkably simple; I’m really impressed with how well that works.
But having done so, of course a lot of links out there in the world (via Google, App Store, etc) that deep-link directly to my old site are essentially broken.
So what I did was move the old website sideways into a new folder, and then I re-created the folder structure being “exposed” by Wordpress for the old site and placed a bunch of redirect pages that just redirect to the new Sitely pages.
The new site is much slimmer in that I chose not to replicate ancient blog entries, or pages for dead apps, but there were still a reasonable number of redirect pages needed.
Now I see that Google doesn’t seem to like indexing redirects, so I’m wondering if this means that the new site is not going to end up being reached via Google after all.
I think I’ve set up the search engine stuff correctly, and the ownership thing (for Google anyways), but it’s all a bit mumbo jumbo thus far.
How do people normally manage the swap out of an older (say) Wordpress site for a Sitely site whilst keeping stuff that matters that is already out there, alive?
I did have a look at the doco pages, but didn’t spot anything.
When modifying the structure of a website, it’s essential to properly manage redirects to avoid losing traffic and to maintain good SEO. I’m not sure which type of redirection you’ve used, but I recommend using 301 redirects, as they inform search engines that the URL has been permanently moved. You can set this up via the .htaccess file (if your server uses Apache). Here’s how to proceed:
Using your hosting provider’s file browser or an FTP client, locate the ”.htaccess” file at the root of your site (where the index.html or index.php file for your homepage is located). If this file doesn’t exist, you can create it by naming it “.htaccess”, making sure to include the leading period.
Then, add a line for each redirect you need to configure, like this:
For example, in this case, any visits to old-page.html will automatically be redirected to new-page.html.
Be careful not to delete any existing code if the .htaccess file already existed. After making these changes, test your site to ensure everything works as expected. If this code doesn’t work, it might mean your server isn’t running on Apache, in which case you’ll need to try another method.
I also recommend the following:
Submit your sitemap to Google Search Console:
Once the redirects are set up, log into Google Search Console and submit the URL of your new sitemap. If you’re using Sitely, the sitemap should have been automatically generated at this address: http://yoursite.com/sitemap.xml. Submitting this URL to search engines will help them index your site’s new structure more quickly.
Create a custom 404 page:
The 404 page is displayed when a visitor tries to access a page that no longer exists. If certain pages have been deleted and don’t require redirection, you might consider creating a custom 404 error page with a clear message explaining that the page is no longer available, along with links to the main sections of your new site. To redirect visitors to your 404 page, add this line to your .htaccess file:
ErrorDocument 404 /error-404.html
(Replace error-404.html with the exact URL of your custom 404 page)
Remove unnecessary old files:
Once everything is set up, you can delete all files, folders, and redirects from your old site. This will free up space on your server and ensure visitors don’t accidentally access outdated content.
I could suggest to you to do your best to replicate the URLs in Sitely, but in Sitely’s case they would end with “html” not php. You’ll need to look into this further.
All your new URLs that doesn’t match the old URLs will need to be permanently redirected as a 301 via your cPanel.
Also you will need to submit your sitemap to Google for them to index your new website.
Ohhhh, I just saw Allan post and he has it totally covered so I’ll leave it at that…
Wow, I’m such a newbie. I set up all these little html files like this:
<!DOCTYPE html>
<html>
<head>
<title>Old Page</title>
<meta charset="UTF-8" />
<meta http-equiv="refresh" content="0; URL=https://www.pkclsoft.com/" />
</head>
<body>
<p>This page has been moved. If you are not redirected within 3 seconds, click <a href="https://www.pkclsoft.com/">here</a> to go to the PKCLsoft homepage.</p>
</body>
</html>
This was what I got when I went hunting. I should have asked here first.
What you have described makes for a much better solution. Thank you so much.
Oh I think I’ll head down your original advised path. I need to make the page work for Google et-al for the future. It also looks to be a much smarter way to manage this. Having a fake folder structure with all these little files, each of which might have a subtle error in them is a mess.
so I have discovered that cPanel provides this functionality, and it works a treat for most pages. But there is a problem when the old page contains a parameter.
For example, my old Wordpress site used a plugin to manage the various apps I have, so a url like:
Thanks yet again Allan. That seems to work, though I’m seeing some other weirdness going on. But the more I look at this, the more I think I’ve approached this whole thing the wrong way.
By placing the new site under v2/ it prevents the Sitely generated sitemap from “just working”. Sure I can edit it to point down into v2/ but thats a maintenance headache. I need to rethink this a bit.
I guess this is a normal sort of headache when trying to migrate away from something like Wordpress when the search engines all know all your old pages.
Looking at some other “migrating” discussions here, it seems that others have managed this process far more effectively than I have.
[update] the weirdness was my browser cache. sorted.
I would advise against migrating your site to a subfolder like /v2. While this might be suitable for testing purposes, it’s not an ideal solution for a publicly accessible site. In the long term, hosting a site in a subfolder complicates the management of updates and structural changes. For instance, if you want to remove /v2 or transition to a v3 version in the future, it would require another migration and the creation of additional redirects, unnecessarily increasing maintenance efforts.
For SEO purposes, it’s better to maintain stable URLs. Google values content updates on existing pages, which can improve your site’s ranking. On the other hand, if the URL changes with every new version, Google might interpret it as a new page rather than an update, which could harm your ranking.
If your site is intended to be a final version, I recommend hosting it directly at the root of your domain. In any case, I don’t think it’s necessary for either your visitors or yourself to explicitly indicate which version of the site is live.