Relaunching your
website can have serious consequences for your search engine
optimization if not planned carefully. Luckily, columnist Stephan
Spencer has provided a comprehensive guide to ensure a smooth
transition.
Has your company outgrown its current website? If so, congratulations on this important rite of passage!
Now, it’s critical to make the revamped website bulletproof from an SEO perspective.
With all the chaos and the huge task list that comes with a site
relaunch, it’s easy to drop the ball on the site’s SEO and thus
seriously jeopardize the link authority and rankings you had built up
over time. The importance of planning out an elegant transition cannot
be overstated.
But what exactly is the plan? Well, that depends on the type of relaunch upon which you are embarking.
New Skin?
If the scope of your redesign is limited to a visual refresh with few
technical changes, then your relaunch is in little danger of
experiencing major SEO snags. However, most redesigns also involve
changes to information architecture, navigation, URLs and so forth.
If that’s the case for you, you’ll need to conduct the right SEO
checkups to ensure the search engine spiders will be able to traverse
your site effectively and find all of your content.
Completely New URL?
Unfortunately, a domain name change can be far more complex in terms
of SEO. These complexities can often result in a loss of traffic.
Some of it simply has to do with user habits. Users can sometimes exhibit
domain bias,
the propensity to click on domains in the search results that use
keywords they used in their query. If searchers are unfamiliar with your
new domain, they may ignore its listing.
Google also has problems trusting new domains. Even if the links 301
redirected from the old site are of high authority, and the site
continues to signal its relevance, the return to high rankings can be
delayed. Google looks at the overall domain age and link equity when
ranking a given site, and changing your site’s URL will impact both of
these metrics.
If you deem it necessary to relaunch your site on a new domain, tread
carefully. Ask yourself if changing to the new domain is worth the
potential short- to medium-term disruption in search traffic.
New Server?
You can handle most of the process of transferring over to a new
server can in a couple of steps. Simply update your DNS and/or go to the
registrar of your domain and change your name servers.
Make sure your server settings and directives are handled correctly.
Sometimes if both the new and the old server run on IIS, the new server
can be configured in a way that transforms all 301 redirects to 302
redirects. The way to prevent this? Double-check.
Also, make sure all legacy code that was ported over is still
functional on the new site. For example, if your new server doesn’t have
Perl and associated libraries installed, you’re going to have a problem
with any functionality requiring Perl.
Whether you are simply refreshing the look of your site or rebuilding
it from the ground up on a new domain with new code, new content and
new design elements, there are several things you can do to ensure that
your relaunch goes smoothly.
Before The Rebuild
Crawl All Your URLs
If you want to successfully move your content to new URLs, you need
to know what you have to move. Crawling your pages can sometimes be more
complex than site owners initially realize, especially when site
navigation is complicated, or there are a lot of pages to the site.
That’s when a good site crawl tool is a godsend. I recommend
Screaming Frog SEO Spider.
This tool will crawl your site and give you a list of every single URL
it finds, as well as a huge range of other information about those URLs,
like title tags, canonical tags, meta-robots tags and much more.
At this point, it’s helpful to also run a check of all of your externally linked pages on
Moz’s Open Site Explorer or
Google Search Console
to make sure you include each page that is receiving link authority in
your content move. Essentially, what you are looking for is any page
with one or more external links pointing to it.
If you are building new URLs, you want to make sure that each of
these pages gets redirected to its corresponding new URL to ensure link
authority is retained.
Map The Moves
Certain systems require you to do each page redirect manually, which
can be a huge amount of work if you have a large site with hundreds of
thousands of pages.
Apache Web server users have it far easier and can take advantage of
Apache’s mod_rewrite module, which allows you to perform the redirect of every URL to its corresponding URL on the new domain with a single rewrite rule.
For Microsoft IIS, the highly useful plugin called
ISAPI Rewrite performs a function similar to Apache’s mod_rewrite.
No matter the system, creating a spreadsheet of where each current
URL is going to be redirected will be incredibly helpful in keeping
track that each piece of content is moved correctly. The main goal here
is to ensure the link authority from old URLs will successfully transfer
to new URLs.
When doing this myself, I use the data from a site crawl from a tool
like Screaming Frog to get a comprehensive list of URLs, then determine
the closest matching URL on the current site. It is time-consuming but
by far the most reliable method.
When moving a ton of URLs that in general follow a pattern (ex.
www.oldurl.com/page1 to www.newurl.com/page1), you may want to create
rules that rely on wildcards and regular expressions, rather than
mapping individual URLs one by one in .htaccess or another server
configuration file.
One thing many site owners don’t consider is the need to also update
current redirects, along with these new redirects. Failure to update
these will result in “chains” of redirects. If the chains contain a
certain number of jumps, you can expect a loss in link equity.
For example, a site may already have a redirect from page a > page
b. If the new URL is page c, then not only should page b redirect to
page c, but page a’s redirect should also be updated to point directly
to page b.
You want to avoid situations like page a > page b > page c >
… > page z. While building this redirect map, it’s also a good time
to check the site and update any URLs that currently 302 redirect when
they should 301, and also to create 301 redirects for URLs that
currently result in 404 errors. You might as well clean all this up at
once.
This map of old to new URLs will also allow you to transfer over
elements from your pages that are currently driving organic traffic,
such as title tags. If one of your current pages is currently ranking
and driving significant quantities of search traffic, you will probably
want to keep the title tag the same, at least for a while, until the
dust settles.
Audit Your Site
I recommend that an SEO expert be involved in your site rebuild from
the very beginning, so that any problems can be found at the earliest
possible stage.
Unaddressed SEO problems that are inherent in your current site may
very well carry over to the new site. For my clients, not only do I
conduct a comprehensive audit, but I also provide SEO guidance at every
stage of the redesign process — the content plan, the functional
requirements, wireframes, mockups, development site, staging site,
launch and post-launch.
Getting an SEO practitioner involved at the planning, information
architecture, wire framing, design and coding stages will ensure the
site gets built right the first time and avoid last-minute re-work and
patch-up jobs.
During The Redesign
Meta Robots Tag Or Robots.txt Directive
Make sure Google isn’t going to hit you with a duplicate content
penalty or simply index what you aren’t ready for them to index yet.
There are two potential ways to accomplish this.
You can “noindex” the pages on your development site, which means,
simply, you are instructing the search engines to not include the pages
in their database of search results. This can be done by adding a
meta-robots tag
with the value of “noindex” to all of your pages. For those running
WordPress, this is accomplished with the tick of a box in your WordPress
admin.
Alternatively, you can use Disallow directives in the robots.txt
file. Technically speaking, you could also issue noindex directives in
there, too, but only Googlebot recognizes that directive, and it’s
unsupported by Google.
Which one do I recommend? Without question, the former. That is the
how you keep pages out of the index in both Google and Bing. Disallows
only stop the spiders from visiting; they don’t tell the engines to
de-index pages that were already discovered through other means.
It’s important to note that a meta robots noindex tag won’t be seen
by the spiders if a robots.txt Disallow is in place, preventing the
spiders from accessing the pages containing the meta robots tag. So
remove the Disallow to allow Googlebot and Bingbot in to see the noindex
tag.
Failing to block your development site from the search engines can
allow it to be indexed. In many cases, particularly if all you are doing
is a design update, the engines add duplicate versions of all of your
pages to their indexes for your development and/or staging sites. Even
if you block those sites after they have been crawled, it can be either a
long waiting game or a very laborious process to remove those URLs from
the indices.
Consider A Phased Approach
This comes from Google webspam guru Matt Cutts himself. Instead of
just making a huge switch happen at once, try out moving a subdomain, a
subdirectory or a subcategory. Make sure that transition works.
By moving it in smaller chunks, it decreases the likelihood of a
spectacular failure. Move it, wait for Google to crawl that section, and
see how it goes. Then, take on the next section.
Update Your Sitemap(s)
This seems simple enough, but it can be easy to forget. New URLs need
to be added to the XML sitemap, and old URLs need to get phased out
over time. Also consider multiple XML sitemaps for different content
types to keep things organized. For example, have a separate XML sitemap
for images.
Remember to add the location of your sitemap (or sitemap index, if
you have multiple sitemaps) to both your robots.txt file and to Google
Search Console, particularly if the URL of your sitemap (or sitemaps)
will be changing with the redesign or relaunch.
Determine Landing Pages For Organic Traffic
You will want to ensure that you have a list of all of the URLs on
your current site that are currently driving organic traffic. You can
find this by going to Google Analytics, to the “Behavior” tab, then
“Site Content,” then “Landing Pages.”
Add a secondary dimension by clicking “Advanced,” then “Medium” to
create an advanced filter that includes the medium containing “organic.”
This gives a list of all the pages that currently get organic traffic.
Is there an equivalent page on the new site? Is there a 301 redirect
plan implemented here? This is a good system of checks to ensure you’re
not losing valuable traffic and link equity. Make sure you have a plan
in place for every page on your site that currently drives organic
traffic.
Launch With A Marketing Blitz
Getting fresh, high-authority links to pages on your new site can
improve Google’s ability to quickly sort out your transition. Obtaining
these links requires marketing effort; this influx of new links won’t
just happen on its own. Plan your link-building campaign early on in the
redesign process, not at the end, once you need the links.
Some ideas to consider: create a contest that ties into the relaunch
or otherwise gamify the relaunch; get your influential industry friends
to countdown to the new site on social media or in emails to their list;
email your list to notify them of the countdown to launch; offer sneak
peeks; create a site launch party; and so forth. Make sure you get the
word out!
Audit The New Site
Make sure you’re starting off on a solid foundation with the
technical SEO elements firmly in place prior to launch by conducting a
technical audit of the staging site.
When you think the site is 100 percent ready to get migration to
production, get an SEO expert to do a full technical audit of the new
site. It’s worth the investment to ensure you aren’t setting yourself up
for problems after you already are up and running — and it’ll avoid
lost profits.
I have audited sites in the past where the site owner contacted me
literally days before relaunch, only for me to find massive SEO problems
on the new site. The relaunch had to be delayed.
If you aren’t well-versed in SEO, you definitely need to get an experienced SEO practitioner involved in your rebuild.
Inevitably, some things will be found which are medium priority or
“nice to have,” but you need to ensure there are no “show-stopper”
issues before you press the “launch” button.
Ultimately, the management team for the site will need to determine
whether to push back the launch or to address these problems after the
new site is up and running.
After The Redesign/Relaunch
Contact Your Linking Webmasters About Links
Run Open Site Explorer to find the top 100 URLs sending traffic, and
contact any webmasters linking to these URLs to encourage them to update
their link. Although your 301 redirects will pass the majority of the
link authority, direct links to the new site are ideal.
Know That The Change Isn’t Going To Be Accepted Immediately
Especially if you are making a ton of changes to a lot of pages and
URLs, it is going to take time for Google to catch on and for your
rankings to readjust to where they were. Accept it, and know that you
aren’t doing anything wrong. But just in case, ensure you haven’t made
any big mistakes by running the following checks.
Watch For 404 Errors
See how Google handles all of your 301s to make sure they are
correctly implemented everywhere. If a 404 does pop up, quickly correct
it with the 301. Google Search Console can take a couple of days to get
caught up to current data. If you have the ability, also have your
system administrator monitor your Web servers in real time for 404
errors.
Run A Safety Check Of Your Important Files
Did you forget to remove the noindex tags from your
development/staging site upon launch? Did you accidentally copy over the
dev site’s robot.txt file with a sitewide Disallow?
Run analytics to check for pages on your site that are strangely
getting views but no referring traffic. And check on the status of your
meta noindex tags and robots.txt.
It should go without saying, but also make sure the pages you do need
blocked are adequately blocked (noindex is preferable over disallow).
Check Your 301 Redirects
If you have a manageable number of redirects from old URLs to new,
check all of your redirects to ensure they were done correctly. If you
have a huge number of redirects, at least check your most important
pages, that is, your former URLs which had the highest number of
incoming links and/or incoming organic traffic.
This is actually reasonably easy to do. Again, I use Screaming Frog
for this. You can manually upload URLs or upload a list of URLs in a
spreadsheet to Screaming Frog and have it crawl just those URLs. It will
give you a report of what type of redirect (if any) that URL goes
through and what page it ultimately results in.
Have a Rollback Plan
If things go haywire, it is nice to know that you have a solid plan
to fall back on. Have a rollback plan ready to execute so you can turn
back on your old site if things just aren’t working out, even if it’s
just temporary.
It is far better to roll back than to scramble because you hadn’t prepared a contingency plan.
Final Thoughts
Site relaunches happen — and frankly, they
should
happen. Regular updates keep your site delivering its best user
experience and allow businesses to maintain relevance, update branding
and more.
However, a relaunch doesn’t have to be painful. Google understands
that redesigns are a regular part of the evolution of a website, and
Google wants to help you to be successful with the relaunch.
With the right organization, planning and auditing, you can make the
transition quickly and painlessly and be able to realize the benefits
you initially wanted for the site relaunch: better user experience,
better branding, updated look, improved functionality, and ideally, even
better organic traffic.
Source : searchengineland