It’s launch day for your new website. We’re assuming that you have read all the other posts in this series and have gone through your website migration planning with SEO in mind throughout - from keyword research and 301 planning to internal linking optimisation and staging site performance optimisation. Now all that’s left is the post-launch check up!
Once your site has been launched there are a few key items you should check before you can be absolutely confident that everything has gone to plan from an SEO perspective:
The first thing you need to check once a website goes live is the robots.txt file. Make sure that:
Next, you should verify your domain (if you haven’t already done so) on Google Search Console and Bing. Verification of your domain on these platforms allows you to easily monitor, maintain, and troubleshoot your site's presence in Google Search results and Bing Search results respectively. This is extremely handy in the days post-migration as Google will flag errors indicative of a flawed migration e.g. lots of 404 pages or lots of pages that are being blocked by noindex tags, messy canonicals, etc.
First things first here - you need to ensure that your dev team have included an xml sitemap. Usually this will be found at https://www.mysite.com/sitemap.xml. If it’s not, check in with your dev team to ask whether it has been added and, if so, where it can be found.
Once you know the URL of the xml sitemap, you will want to submit it to both Google Search Console and Bing Webmaster Tools.
We’ve already discussed the importance of 301 redirects in a previous post. To recap, correctly configured 301 redirects will:
So to ensure that your users and crawlers are not getting lost and to make sure that you’re not losing all your hard earned SEO value built up on the previous version of your site, you will want to test that your redirects have been implemented correctly.
You have a few options with regards to how you choose to do this. You can:
You’ve already checked the staging site to ensure that crawl depth is not a big issue. But it’s always safer to check again once your site goes live. Check out our post on Reviewing Your Staging Site for detailed instructions here.
Again, you’ve already checked this on the staging site but it’s prudent to ensure that the page performance optimisations have been carried through to the live site and nothing has been added to the site that is slowing down pages or affecting Core Web Vitals negatively. Check out our Staging Site Performance Review for SEO post for detailed instructions.
As part the SEO checklist that you provided to your developers way back at the beginning of this migration project, you explained the importance of canonicalization on the new site that references the new site and not the old.
At this stage you should test that important pages on your site have canonicals that point to themselves, rather than pointing to other pages especially not to their equivalents on the old version of your site.
You have a few options with regards to how you choose to do this. You can:
Structured data in the form of schema.org markup helps Google to better understand your organisation, your site and your products and helps you to gain richer results on the SERP for higher CTRs.
In our SEO checklist at the beginning of the site migration process, we recommended to add schema.org structured data markup to your website in order to specifically explain to Google your sites association with specific topics, brands, products, services, people and other entities.
S0me types of Schema.org markup and their SEO benefits:
After having gone to the effort of adding schema.org markup to your pages, you can test each page individually with the Schema.org Validator. Google Search Console will also flag issues with Rich Results via the Enhancements report.
A custom 404 page allows users to easily navigate your site and find something useful if they land on a page that no longer exists.
As part of your Technical SEO checklist you will have requested that your devs ensure that if a page does not exist on the site, the user is presented with the custom 404 page (whilst maintaining the URL that the user tried to access).
You should also ensure your 404 page is engaging and user friendly and, critically, that it triggers a 404 response code.
A quick test to see if broken URLs are properly serving a 404 response code:
1. In Google Chrome, go to a URL on your domain that you know does not exist e.g. www.adaptiveco.io/bla-bla-bla
2. Right click, select Inspect to open the developer tools
3. Select Console tab
4. Reload the page
5. You should see a message something like “GET https://www.mysite.com/bla-bla-bla 404”
Alternatively, you can use a Chrome plugin like Ayima Redirect Path plugin.
Now that you’ve completed your SEO Go Live Checkup, your site migration is complete! I’d like to say that the work stops there but unfortunately SEO is not quite as simple as that. Over the next few weeks you will want to keep an eye on your Google Search Console for errors, your web analytics for any glaring traffic drops and your rank tracking tools for any significant dips in rankings.
And of course, you’ll want to put in place an SEO strategy that includes ongoing content creation and link building tactics as well as keeping on top of the technical aspects of your site. If you’d like to chat about developing an SEO strategy for your website, feel free to get in touch with our SEO team!
In the meantime, check out the other blog posts in this series on SEO for a Website Migration: