With each new year and every new (ever-harder) marketing goal to hit, you are probably considering making changes to your website. These might include a new, easier-to-use design, a better content strategy to grow your customer acquisition funnel, or a complete overhaul based on a new digital marketing strategy.
With every website change comes challenges – specifically in terms of search engine optimization (SEO). It’s far too easy to make positive changes that improve some marketing goals, while accidentally decreasing SEO/organic traffic. But it doesn’t need to be that way!
So, how can you best set yourself up for site changes + SEO success?
It’s best to understand what kinds of changes you are making to your website, and the relative SEO risk those changes bring for your organic search traffic. This can help you plan for the kinds of SEO tasks you should tackle, so the work you do will result in more, not less, SEO traffic over time.
Design-only changes – without any structural or URL changes – tend to be the “safest” kind of migration you can carry out.
Note that in this case, "rebranding" refers to visual changes only; if your brand changes names & your domain does too, see the section on Domain Migrations below.
Recommendation: Crawl your stage site (complete with redesign changes) with JS and CSS disabled. Check all major page template types to ensure that all content is accessible/readable on the page when it’s turned off. If/when content is missing, work with your development team to make it visible.
Don’t worry if it’s ugly – a site without CSS is pretty much guaranteed to be so!
Server changes, with or without any other site changes, present risk primarily in terms of page load speed. Load time is an SEO ranking consideration, but perhaps more importantly, it’s a conversion issue – after all, what’s the point of any marketing channel if it isn’t selling your products or services?
Changing server types or service providers can be another issue:
Moving from Apache to Nginx or IIS, in terms of the rules that apply to redirects. Example: if you go from IIS to Apache you'll find out that the case-sensitivity of a URL matters. Conversely, Apache uses .htaccess, but IIS and Nginx don't. Hat tip to the fabulous Anne Hennegar for this insight!
Moving to a new location (or server service provider) may mean that some functionality you previously depended on is no longer available. Ensure you are vetting the services for the functionality you need when making this change; server providers are NOT inherently interchangeable.
Set up a staging site on the new server, and compare your existing site’s page load speeds against the new server’s load speeds. Aim for page load speed improvements!
If you are changing server types, double-check all your redirects to ensure they behave as expected.
URL changes (e.g. from old URLs to new URLs) present both SEO risk and SEO opportunity.
Any change to URLs (at least, those URLs that are publicly accessible to Google & other search engines) forces said search engine to re-evaluate each specific page again and re-rank it against all other pages covering the same subject. This takes time to carry out and therefore can hurt your short-term SEO results. However, making URL changes to more SEO- and user-friendly language can improve SEO in the long run.
Also note that URL changes often come with design changes, so you should consider those risks/recommendations as needed.
Be sure to consider SEO when selecting your URL naming conventions – in addition to all the other important considerations like strategy, branding, accuracy, etc. – and base those decisions on solid keyword research (aka data) & a keyword strategy that is reflective of your overall business & marketing strategy.
Redirects are a huge consideration for URL changes and should be considered and implemented part-and-parcel with any URL changes.
Note that this doesn’t mean all URLs that change must be redirected, but that it’s very likely that most should. That’s another topic for another day...
Platform (CMS) Migration
Your platform is what your site is built on. You could have a custom site, an SPA (single page application,) Wordpress (the best-known CMS), Shopify, or any number of other services.
Platform changes can be more or less risky, depending on the system you are currently using and the platform you are migrating to. It sounds simple and obvious, but moving to a platform that offers less control over SEO details can mean that existing optimizations and flexibility will go away.
Outside of that risk, platform changes are also risky due to the URL rewrites, which are frequently required to fit within the structure and conventions that each system requires.
Design changes are frequently a part of a platform move.
Be sure to vet your proposed new platform for all your business needs, including SEO functionality.
Note that this isn’t an initial site from scratch (with no previous versions). That doesn’t really have much risk, other than the risk of not getting good organic traffic in the first place. :)
Refreshing your entire site could be the result of a completely new business direction (hello, pivoting!) or the realization that your existing site just doesn’t do its job. Regardless of the reason, a completely new site — including design & structure & content changes — brings with it a fair amount of risk.
Domain migrations are generally considered the riskiest changes for SEO, according to basically every SEO blog. This is because changing your domain name (e.g. www.thisismysite.com to www.ohheyimovedit.com) means that each and every URL on your site will change. It also frequently means design, content, and structure changes. Hence the very-high risk assessment.
Consider working with an SEO firm you trust to help you through the eCommerce migration process.
Whether or not a site should migrate to HTTPS (a secure protocol) vs. HTTP is a subject of much debate among SEOs. Sites that have migrated have seen results all over the board. But at the end of the day, your core homepage URL is changing - so this is not an inherently "safe" migration type.
Regardless of which side of the debate you’re on, should your business choose to move forward with an HTTPS migration, you should know that changing this protocol does, in fact, constitute a sitewide URL change. Therefore, the “URL Changes” migration type should be reviewed to understand the risks therein.
Note that an HTTPS migration is not as risky as a Domain Migration, despite the fact that it’s also changing 100% of your URLs. This is because Google has officially recognized it as a ranking signal, which counteracts (at least somewhat) these URL changes.
Ensure you aren’t making this change purely for SEO ranking reasons, because, chances are, it’ll hurt in the short term. There are, however, many good business reasons for making this change.
In general, the Web is moving to HTTPS. It’s just a matter of time. So consider timing this change in a way that works for your business’ needs and seasonality, in order to limit SEO pain.
Much like the world we live in, migrations can come in all varieties, shapes, and sizes. Consider the list above a shortlist of the major concerns. If your migration fits in more than one bucket from above, all the concerns/issues should be addressed (e.g. these issues are additive.)
Once you’ve determined the migration risk, you should spend time considering:
Is this migration project worth the risk? Only you can make this decision, but carefully weigh the risks vs. the metrics/results you hope to gain from the project. Consider putting it off if it’s not critical.
Determine the best time to do the work for your business. When is the best time to complete a migration? Generally you need to consider the urgency of the work needed from the migration vs. your core seasonality, e.g. if you are an ecommerce business, you should not be migrating your website right prior to Black Friday (obvious point - lower SEO traffic or a broken checkout process will impact your business!) Instead, in this case, put it off until after your big selling season ramps down - giving you the largest amount of time possible to recover from the migration prior to your next seasonal upswing.
General SEO Website Migration Recommendations & Best Practices
Plan for evaluating new platforms and/or themes against all your SEO needs, in addition to all your regular business and marketing needs. Clearly document what you need from these tools, how critical each item is, (as in, is it a deal-breaker if it doesn’t have it? Or just more annoying?) and whether or not each of your proposed new solutions offers each item on your list.
Heavy testing with GSC's Core Web Vitals report (or Lighthouse, PageSpeed Tool), to ensure you minimize the pain of this transition. Site performance matters - critically.
To be clear, JS does appear to be the future of website development and user experience.
That doesn't mean Google's ready yet, or that your website is.
Put together a migration & deployment plan that accounts for SEO in addition to technical and marketing considerations.
We very much recommend building SEO QA & issue fixing time into your plan; you can anticipate some issues ahead of time by doing a good job vetting your new changes in the first place. However, there is really no substitute for crawling & evaluating the development site to identify and fix issues prior to pushing your changes live.
Don’t forget about tracking! I can’t tell you how often Google Analytics and GTM tracking breaks upon migration - either due to inconsistent tracking, or goal funnels that have changed. Without good tracking it’s (obviously) much harder to determine how successful, or not, a migration is. Or, it can give you a panic attack when your traffic “disappears” overnight. Make sure to check your GA & GTM tracking setup to ensure this is not a concern.
Define a "Successful Migration" for your organization.
In other words, set expectations well. Even the best-planned website migration projects can go awry. Generally speaking, not losing organic traffic is the key KPI, or perhaps minimizing those loses. Gains are possible, but should not be counted on - especially if/when you are making URL changes, or aren't actually improving the site from an SEO perspective.
Should you choose to move your SEO forward as a part of the project- say, by reducing duplicate content dramatically, or adding new features like schema markup - gains may become more possible.
Document your existing keyword rankings, best landing pages, traffic data, etc. for the last 3+ months. GA (Google Analytics) and GSC (Google Search Console, formerly “Webmaster Tools”) are great tools for this.
The goal here is to have a benchmark for existing performance, so you can a) evaluate how successful the migration was, and how long it takes you to recover from the changes, and b) if/when something goes wrong, this data can help you dig into the differences, allowing you to better troubleshoot and fix any issues that arise.
Keep in mind that almost all migrations – at least, those that include URL changes – involve some temporary SEO traffic losses. But if you haven’t seen traffic rebounding / returning to normal after 1-3 months, something may be wrong.
Claim all URL variations in Google Search Console. This includes:
All subdomains, including the site with and without www
HTTPS vs. HTTP, if applicable
All combinations of these. An example for a standard HTTPS site:
Crawl the site using your preferred crawler of choice. I’m a big fan of both DeepCrawl and ScreamingFrog.
Document your Google Analytics migration plan, so you don’t break traffic or goal tracking. Doing so really makes it hard to measure, well, anything, but mostly how the migration is going.
Document anything that could/should be improved prior to or post-launch, including your metadata, on-page copy, alt tags, page load speeds, structured markup, canonicals, noindexes, etc.
Phase 2: Audit the Development Environment (New Site)
Ensure that your dev site is “SEO QA ready” before beginning in order to reduce the chances of wasted work (and/or work with your development team to test specific changes when they are ready.) This generally means all functionality is complete, all content is in, all changes are made, etc. The site should be “dev-complete” in almost all cases for a final SEO check.
Ensure the dev site isn’t indexable — you don’t want your stage site in Google! Generally, this is as easy as blocking all user agents in your robots.txt file.
Set up & QA redirects as necessary. Always use a 301 (permanent) not 302 (temporary) redirect whenever accurate. Only use 302s when the change is literally temporary, and you will be building the new resource after the fact.
You can check this by inputting the URL in question in the header checker of your choice, or use Screaming Frog to check all of these status codes.
Phase 3: Compare the Live (Old Site) vs. Stage (New Website) Sites
Crawl the dev site & live sites, and compare/contrast the differences.
Are all the pages there? Is all the content you’d expect on all those pages? Is the metadata (titles, meta descriptions & headers) equivalent to or better than what’s on your live site? Etc.
If you are intentionally retiring old pages, make sure to vet those decisions carefully. Choosing to remove a page - with no real new equivalent page - no with too many backlinks can be disastrous.
Fix any broken links (404s and 500s), and links to old page (301s and 302s) patterns– errors you don’t introduce to Google aren’t really errors, after all!
Browse the site with multiple devices. We’re living in a mobile-first world, and UX matters across devices.
Check various page templates for mobile-friendliness and page speed issues. Fix them!
Browse your site with JS & CSS turned off. Ensure you can access all content & links.
Dropdown navigations are notorious for not working in this scenario, and you can and should build a work-around!
Work with your development team to fix and QA all issues prior to giving them the “SEO All-Clear” to go live.
Phase 4: Go-Live Migration QA
Build in time to QA the site once it’s live! This is a critical step to ensure all went well.
Check your robots.txt file – you shouldn’t be blocking all search engines (Google, and others like Bing) anymore!
Check robots meta tags and canonical tags (assuming you are utilizing these) to ensure they are used accurately, and that you aren’t accidentally setting "noindex" on pages you want indexed.
Check your redirects – do they all work as expected? Also, check in on broken pages in GSC, and set up redirects as needed for any new issues Google finds.
Check GA – is your data collecting? Are your goals still tracking?
Crawl the live site again.
Ensure there are no broken links (that includes internal links AND external links) –- and no links to the stage site. If there are, fix these ASAP.
Verify that all the changes & content are as you expected.
Submit your site to Google for a re-crawl as needed.
You can do this by submitting a new XML sitemap of the new/updated pages, or by submitting each URL individually (not recommended unless it’s just a few pages!)
If your website is changing domain names, you’ll need to submit a Change of Address form in GSC. In the tool, you'll map the old domain name to the new domain name to give Google specific clarify about what's happening.
Phase 5: Post Migration Monitoring
Watch GA and GSC for fluctuations in the days, weeks and months following launch.
Perform cleanups as needed (actually implementing & deploying these fixes in a timely manner is critical!)
If you see greater-than-expected drops in traffic, use the documents you collected in Phase 1 to understand why (e.g. which pages are seeing drops in traffic? Are other channels dropping, like PPC, or just organic traffic? Is something wrong with those pages? Etc.)
Successful site migrations can be complicated, but if you know what you are getting into and you have a plan to accomplish it, you can succeed.