Whether you are launching a brand-new website or migrating to another platform (and/or domain), these projects can end up very stressful and often ridden with mistakes. As a result, you may have to resolve these issues either just before site launch, causing delays, or after site launch.
However, like any big complicated project, if you have a good checklist and team who knows what they are doing, with realistic deadlines you can succeed and seamlessly transition to a new site with no hiccups.
Trust me. I have been a part of numerous site launches and I have learned a great deal from each experience and the knowledgeable partners and colleagues I have worked with over the years!
Jump to topic:
- Common Mistakes
- Examples of it going wrong
- Map out the project (example)
- Before site launch
- Content migration
- 301 redirects
- HTTP to HTTPS redirect
- Tracking Code and Goals
- Google Search Console
- Address performance issues
- Perform a technical SEO audit
- Site speed
- Mobile usability
- Test the UX and conversion points
- Site launch and after
- Launch in a low visitor time of day
- Monitor Google Analytics
- Monitor Google Search Console
- Monitor rankings
Before I get started, I thought I would list some common mistakes I have found during the many web build/migration projects I have taken-on after they were started, or while observing with a limited capacity to action changes myself.These are some of the few recurring issues I have come across, however, I have listed a checklist of the main things to consider below to help you through this process.
|Issue||Effect on website / campaign|
|Tracking codes missing / not properly implemented||Data skewed, can’t,fully report on effects of project via historical data|
|Not migrating,content||Loss in authority,,rankings, traffic, conversions/sales|
|Existing / proposed,new content doesn’t fit new website template designs||Migrated content may,lose its context / may not be as engaging with new layout|
|Redirects,missing/incorrectly implemented (e.g. mapped to wrong pages / 302 instead of,301 redirects)||Loss in traffic,,rankings, site authority, increase in 404s and soft 404 errors|
|Google Analytics,Goals not updated for new confirmation pages/call-to-actions||Data skewed, can’t,fully report on effects of project via historical data|
|Robots.txt file not,updated for new domain / site structure||Rendering previous,statements redundant and potentially making hacking easier / effecting,indexation|
|Not leaving enough,time!||Unrealistic,timescales have a knock-on effect on the whole project, causing a rush of,work towards the end which can lead to complacency|
These are some of the few recurring issues I have come across, however, I have listed a checklist of the main things to consider below to help you through this process.
Examples of it going wrong
Here are some quick examples of site launches going wrong:
A reduction in indexed pages from 8,000 to 2,800
In this example, a site went live with a large amount of 404 errors from missing pages and as a result the number of indexed pages reduced significantly. We also saw a drop in keyword/brand visibility and organic traffic too.
Vast increase in 404 errors reported in Google Search Console
As a result of missing 301 redirects, the 404 errors have increased from 800 to over 100,000 which need resolving after site launch. When users were hitting these 404 pages, whilst both browsing the site or entering it from external links (from content marketing, email shots, bookmarked pages) they tended to not continue through the site. Not knowing how to find the next related material, this caused a rise in bounce and exit rates, reducing engagement and conversions.
Over a longer period of time there was a drop in returning visitors as trust was lost.
Reduction in organic traffic year on year
We see data from over two years; with an initial drop in organic traffic in October 2015 (the time of the migration) and a continued drop due to a project ending and no recovery work being done. This looks more alarming when comparing against the previous year.
A reduction in goal conversions
Here, goal conversions dropped off completely as a result of event tracking not being reconfigured once the switch to the new site was completed.
A reduction in eCommerce transactions
An example of an eCommerce site reducing in transactions by -64% in the period after site launch compared to the previous year. Due to loss of traffic from missing content and poor indexation.
A reduction in keyword visibility
In this example, the organic keyword visibility score (blue dotted line) dropped significantly due to pages with optimised content not being migrated and redirected to a new site and meant a significant reduction in organic visibility.
Planning: “failing to prepare is preparing to fail”
I find the best way to plan for a website launch or migration is to:
- List all of the actions relevant to your project by priority scores
- Identify all of the people responsible and assign them to each (consider assigning multiple people on crucial tasks in case someone is unavailable at a crucial moment in the project)
- Map each action to a deadline along a “realistic” timeline
Map out the project (example)
Consider a Gantt chart or similar to properly map this out and consider the proper time needed for each task. Be generous if you can, allow some leeway for unexpected hiccups, which there always tends to be. My example above is quite generous in time scales, but people do commonly underestimate the time needed for the below tasks:
- Design stage: sometimes there might be a lot of back and forth and amends
- Redirect planning and mapping: this almost always goes wrong if you don’t spend time on it!
- Content migration: particularly for very large sites where you need to evaluate content first and choose what to migrate or redirect. Also, platforms like Magento 2 might make it difficult to migrate certain pages
Consider using project management tools to keep a centralised communication hub for all stakeholders, emails alone can get messy! Two of the best ones I have used are:
Before website launch
Typically, before site launch you will have chosen a domain/platform, gone through template designs, navigation mapping, UX design and so on. As this is a separate beast we won’t cover that part in this post, instead we will focus on a core checklist for a site launch.
Content is a key part of any website whether you are doing PPC (helps quality scores), SEO, to help maintain and build on existing organic visibility, or simply to offer a valuable user experience
There are two typical ways you could migrate content:
- You can opt for a straight like-for-like migration, where all pages are moved across to a new domain/structure and redirects can be applied afterwards
- Or you can use the opportunity to audit each page to see which are worth migrating, consolidating or simply redirecting.
For example, I may be tasked with migrating several websites into one single domain, this means consolidating and redirecting a lot of content and pages. How do I decide which get moved/redirected? By auditing the pages to determine their value to users and Google using analytics and website crawling tools to highlight good/bad points of each page and decide based on the results.
The steps I take here are to:
- Use a tool (DeepCrawl / Screaming Frog) to pull each page on these sites and the status of those pages (any 404 pages, word counts on them, load times, internal links, external links, is there any duplicate content and so on)
- Use Google Analytics and gather all landing page data including organic visits, bounce rates, average session duration, pages viewed per session, conversions/sales and conversion rates
- Use Ahrefs Batch Analysis tool (or similar) to gather page authority data, estimate social shares, backlinks, domain links
- We can then collate all performance data to one Excel sheet through a Microsoft Excel INDEX and Match function, see the link for the function and example if this done below:
Note: you could also use tools like Supermetrics where the browser plugin will pull data from several sources into one sheet. It is much easier but you do have to pay for the tool.
The result after you do all of this is can be seen in the screenshot below where I have data from Analytics, Ahrefs, Screaming Frog and DeepCrawl. Using some conditional formatting in Excel this can then tell me if a page has, for example, a good page authority, bounce rate, number of visitors and conversions/conversion rates amongst other performance metrics. I’ll sort these by best performing metrics and look for patterns in the URLs for which sections of the site are the best.
So here I have a list of landing pages and performance metrics from four sets of data (different tools) to give me an idea of which pages hold value to the user and to Google. I will want to migrate most of these pages as they have a good amount of content, page authority and engagement and redirect the rest to relevant pages.
If you are looking at pages that discuss near identical topics and see weak performance metrics on them, consider consolidating them into smaller pages. This re-purposing and consolidation of the content can make two weaker pieces into one stronger and more effective piece.
In addition to the actual content, all of the elements within these need to be migrated too as these will affect rankings, click through rate and engagement. These include:
- rich media
- image alt tags
- title tags
- meta descriptions
Now redirects are a real big issue and a personal bugbear! Most people make the same mistakes with this task.
If your domain or website structure is going to change, you will need to account for this by creating a redirect plan, essentially mapping the old pages and folders to their new locations. This will prepare your developers to then create the redirect rules that physically take the user from “old pages” to “new pages” should they still try and access the old page via a bookmark or external link.
You also need to make sure that if you are moving pages to new permanent locations that the redirects need to be a “301” redirect. This type of redirect tells Google and other search engines that this is a permanent new destination and so to assign all of the SEO authority gained from the old destination to this one. If however, you are moving to a holding page or other temporarily destination you can use a “302” temporary redirect, this passes on no SEO authority and informs Google that the destination is temporarily, thus do not permanently select these pages to rank for any search queries.
Sort out 404 existing errors before you start!
One crucial consideration before this however: do you have any current 404 errors on the site? If so, include these into your new redirect strategy and point them to the new pages so as not to create redirect chains.
- Check in Google Search Console under for 404 errors (filter out old errors)
- Use a tool like DeepCrawl or Screaming Frog to check for 404s (focusing on any internal broken links)
- Combine both data sets and de-duplicate them in Excel – that’s your final list
Include existing 404 errors into your new redirect plan, that way you are taking the user directly to the new page on the new site, rather than redirecting them from “Page A” to “Page B” then to “Page C – new site”, thus avoiding a redirect chain which can take website authority away and slightly effect your website load speed.
The redirect plan
- Map out all like-for-like page redirects in excel side by side
- Ensure the new destination pages are discussing the same topic as the old ones, if they do not they may have been flagged as soft 404 pages by Google and the redirect may be ignored
- Keep your list of old and new pages – this will help you later when you are checking the redirects after they are live
Consider an HTTP to HTTPS redirect while doing main redirects
- A secure website (HTTPS://www.smug-secure-website.com) is becoming more important because:
- Given a slight ranking boost in the Google search results, though the level of this boost is small (see more on this here http://searchengineland.com/google-starts-giving-ranking-boost-secure-httpsssl-sites-199446)
- According to Google, 50% of all desktop webpages are HTTPS secure and growing (as of January 2017) so it stands to reason that it’s better to join other in making the online ecosystem secure, if not to just ensure your site is marked as safe and getting the most exposure
- Google Chrome now alerts a user if a website is secure or not, this will prompt the user to decide on whether to continue onto the site or not (see a post we wrote on this https://anicca.co.uk/blog/2017/01/25/why-your-website-needs-to-be-https-by-the-end-of-january/)
If you are creating redirects during this site launch/migration process and you do not have a secure website why not consider adding this to your task list too, as you would have to do redirects again later anyway.
Consider these steps:
- Based on what type of site you have (lead gen, ecommerce, small/large) look for an SSL Certificate package that suites your needs with your developer, an example is from: https://www.123-reg.co.uk/ssl-certificates/
- Once purchased, a developer will need to install this onto the site (see this guide to help: https://www.123-reg.co.uk/support/answers/SSL-Certificates/SSL-Explained/how-can-i-add-an-ssl-certificate-to-my-domainwebsite-627/)
- You will then need to redirect all HTTP (non-secure) URLs to the HTTPS (secure) URLs via 301 redirect rules, this should be very straight forward with re-write rules, just replacing the un-secure URL versions with secure versions
Tracking Code and Goals (with call-to-actions)
Whether you are just using Google Analytics, Tag Manager or other tracking methods, these need to be moved across to all new pages. You also need to migrate or re-created event tracking on call-to-actions and add eCommerce tracking to confirmation pages for eCommerce sites.
Consider these steps:
- Take note of all tracking codes (say you have Analytics, HotJar, ResponseTap etc) and add them to your template files on the new site
- Take note of all current Goals set up in Google Analytics and change any current event tracking on call to actions or confirmation URLs and replicate/migrate to their respective new locations
- Use this opportunity to evaluate the goals you are tracking and add any new Goals needed for any new layout changes / new call to actions.
If you have not implemented Enhanced Ecommerce Analytics yet, consider doing this during migration by setting it up in Google Tag Manager. The benefits of this more powerful form of reporting includes seeing shopping and purchasing behaviour, product attribution, merchandising behaviour, economic performance and much more. See this guide to get started.
If you are not using Google Tag Manager already consider using this opportunity to consolidate all of your tracking into Tag Manager. This platform is so powerful and convenient when making changes to anything on your pages such as tracking, meta tags, CSS file additions etc. View this guide from Google to get started.
Google Search Console
It’s important that the data in your Search Console Account is constantly flowing before and after site launch. During site launch and after you want to look for discrepancies in indexation rates, 404 “page not found” errors, 500 “server errors”, check if the site goes down, sitemap.xml performance and Search Analytics data and so on. This will help you monitor website performance to gauge how well the site launch/migration went.
Consider these steps:
- Remember to re-verify the site once migrated either via Google Tag Manager, Google Analytics or manually by placing the verification code in the head section of your template pages
- If you are changing your domain then at the time of the site launch use the “Change of Address” process and re-verify the site using head tag or analytics
- If you are migrating to HTTPS, create an additional account for this domain version
- Re-submit your XML sitemap file once generated. Hit “test” to see if there are any validation errors and check back to see if enough pages have been indexed from the list of URLs
- Re-submit your robots.txt file once regenerated/edited for new layout, check for any validation errors by hitting “test”
A simple task in most cases, especially if you have a Content Management System (CMS) that will re-generate a new sitemap (WordPress, Magento etc). This file helps search engines find your pages and index them and it helps you keep track of how many pages are getting indexed in Google Search Console, this helps you optimise for your Crawl Budget (see link that explains this).
Consider these general steps:
- Ensure an up to date sitemap is created and is set to update automatically when new pages are added / or re-generate every week/month (depending on whether you have a large/regularly updated site such as an ecommerce site)
- Add the sitemap/s to the robots.txt file
- Re-submit the sitemap/s to Google Search Console
XML Sitemap Generator – https://www.xml-sitemaps.com/ – Quickly generate a sitemap if you have a small website (under 500 pages).
An important file that helps you restrict what search engines see and index on your site. If you are changing the structure of your site you need to change the references to files/folders and the sitemap if this file name changes.
Consider these steps:
- Change any disallow /allow statements that refer to old pages / folders / files with their new destinations
- Add any new pages/folders/files from the new site structure to help improve your crawl budget
- Add the new sitemap at the bottom to help Google find it
- Upload the new robots.txt file to Google Search Console and test it for any errors
Address performance issues
Set up a BETA test site test functionality, UX, speed, mobile usability and responsive design, technical and on-page SEO elements. Address any website issues before launch to avoid them occurring when the site goes live.
Perform a technical audit of your site
You can flag any current issues (like the 404s discussed earlier) beforehand provided you have a BETA test site to play with. Using a tool like DeepCrawl (do I sound like I work for DeepCrawl!?) you can easily flag issues and fix them beforehand, such as:
- Duplicate content
- Missing title tags, meta descriptions
- Multiple H1 tags
- Mobile usability reports
- Thin content
- Code vs text ratio
- And a load of other things!
If you have a slow loading site why not address some of the issues causing this during the migration.
Common issues that can cause a slow loading site include:
- Images not optimised for web
- Too many landing page redirects or redirect chains
- For large multi-regional sites; lack of a Content Delivery Network (CDN)
Useful tools to start diagnosing issues:
The Google index will prioritise mobile websites first when indexing your site moving forwards, with the desktop version prioritised second. Together with the fact that mobile users outweigh desktop visitors now, it’s important to ensure the new site is mobile friendly.
Useful tools to start diagnosing issues:
Test the UX (User Experience) and conversion points
You could use an existing client base and send them the new site to test elements or use internal staff and look through:
- Conversion points
- Responsive design across a sample of browsers/devices
- As for a rating of the new site’s design, layout, functionality (consider setting up a free Survey Monkey questionnaire and incentivise the survey if you need to)
Site Launch and After
Relative to the time zone you serve, you should consider the ideal time to launch your site. Typically, it’s better in the early hours of the day, though consider the industry you are in. For example, if it’s a betting/video on demand site for example, you will need to just check in Google Analytics when this is.
- Go to “Customisation” and “Custom Reports”
- New Custom Report
- Add a metric for “Sessions”
- Add a dimension for “Hour” and hit save
- Choose a generous date range (ideally 1 year minimum)
In the graph below traffic is lowest between 00:00 to 05:00, in this example I would choose 04:00 to 05:00 to get things uploaded.
It’s important to get an idea of the performance trends in Google Analytics before you migrate your site to get an idea of the normal behaviour and any recurring quirks (including seasonality) so you know what you’re looking for when monitoring after site launch.
- Keep in mind any changes in site content; if you have consolidated a lot of content and/or redirected a lot for example, then you would expect to see a drop in organic traffic and rankings.
What you want to look for in this monitoring period is:
- All traffic channels (in particular, organic traffic will focus on how the site now looks in Google, diagnosing any indexation/optimisation issues relating to content and technical issues)
- Compare year on year to clearly spot any differences from before and after site launch
- Any drops/spikes – check real-time session data too in the first few hours after migration is complete
- Session durations, pages per visit, bounce rates (if you have a drastically new site design these might change for the better or worse)
- Conversions and conversion rates (changes in layout and calls to action might affect this too)
If you see any drops in the above that you didn’t account for then we would recommend going through the changes you have made to content, optimisation, layout, calls to actions and so on and working backwards to see how you can improve these performance metrics.
This free and powerful tool becomes indispensable in situations like site launches, especially if you have previous data to compare to.
You want to ensure that the number of pages indexed is in-line with the pages existing on the site, and that rate of indexation is constant and unaffected against the previous rate.
Pay attention to these key metrics:
- Look for messages: you might have a message indicating the site was down for a period of time, or that there was an increase in 404/500 errors
- Monitor new sitemap submission status and pages indexed from it – look for discrepancies in pages “submitted” vs “indexed” and compare against historic data
- Check the indexation rate and compare against previous periods on the same graph
- Monitor crawl errors and add-to your redirects based on this data
- Especially if you have designed a new site; check for render blocking scripts to see if any important visual scripting has not been “allowed” in your robots.txt file
- If you are tracking keywords for SEO, use a tool like “SEO Monitor” tool or similar, monitor rankings and visibility scores and look for drops/climbs
- If you see drops, look for the specific pages affecting this and check if they are on your migrate list, consolidate or redirect list, you may need to reinstate pages of value
You could monitor ongoing performance of user activity through software like HotJar and tag call-to-actions and other elements like videos in Google Analytics that will show you:
- Heatmap data
- Visitor funnel data
- Visitor journey recordings
- Conversions and conversion rates for call-to-actions
You can see where visits drop off or what elements do not perform well and adjust the design based on this.
There are a lot of things to consider when launching a new site and it may seem daunting when reading this checklist. However, if you plan for this and have a team around you with expertise that are dedicated to the goal of a smooth launch then you should have no problems.
We can help!
Anicca Digital’s Technical SEO team have launched many websites, you name it: small, medium, large, ecommerce, lead generation, and complex international sites tied into external marketing campaigns. With planning and expertise we have been able to launch websites smoothly and we have the references and reviews to prove it.
If you would like our help launching or migrating to a new site please call us on 0116 298 7482 or contact us using the form below and we will be happy to talk this through with you.