SEO and Website Migrations: How to Have a Smooth Transition – SESNY

This is the fullest session I’ve attended yet. The SES NY audience must be interested in the technical SEO track. Jessica Bowman is our presenter. Here’s a video interview I had with her about the challenges of in-house SEO. Today she’ll be talking about one particular task that an SEO might undertake, and that’s a site migration. There are several phases of dev life cycle. If you’re going through a redesign/redevelopment project you’ll have to go through these phases.

Requirements Phase

Project kick-off, the challenge: SEO isn’t top of mind for the rest of the project team. They’re not accountable for SEO success metrics. This means you need to train on SEO, but not everything. Just the things they need to remember for the project. This is the time to identify what isn’t right with the site. You also need to identify what you want on the new site at this point.

The reality is that at the requirements gathering phase, most SEOs aren’t sitting in all meetings, so SEO risks are not addressed. Many SEOs do not know how to define complete SEO requirements. What to do: review all project requirements and consider a third party (if you don’t have experience with this type of project). You should carefully review all requirements provided by other departments.

Canonical tag

It’s kind of like a bridge between the way things are coded and the way it should be coded. She’s concerned with how she’s seen the canonical tag employed. It’s NOT a bridge – it’s band-aid. She’s seen funky instances of it used as a body cast. Search engines are recognizing that the canonical tag is not being used correctly. Think back to 2009 and the nofollow tag issue. The nofollow tag was used to not pass value from one page to another. SEOs used it for PageRank sculpting, strategic flow more value to specific pages on the site. This happened for a few years, until 2009 at SMX Advanced when Matt Cutts said it’s probably not working the way you think it’s working. She’s concerned the same type of thing will be revealed about the canonical tag.

The canonical tag is important: tell the search engine that content is the same and that credit should be given to said page. It’s a useful tool but stop and make a plan for how to use it. Just know it’s a signal, not a directive. Use it where you must but avoid where possible. Code in a way that does not rely upon the canonical tag.

Write specific requirements for how to use canonical tag for: pagination, multi-faceted nav, list ordering, pages with tracking codes, sites with parameters that are optional, printer-friendly pages, pages with duplicate content.

Changing URLs

Remember that every URL has a value. Whenever you implement the 301 redirect in a large org, it can turn out like a tornado – think about how to strategically define a migration plan. Make sure everyone in the org understands some value is lost when you change URLs. Preserve what you can with a 1:1, “permanent 301 redirect.” (Reference it the same way every time so developers know exactly what to do.)

Defining New URLs

Ideally, URLs will never change. Choose wisely. We want URLs to outlive the lifespan of this particular design.

Brief set of URL requirements:

• Avoid parameters. If must use parameters, merge them.
• Use a dash instead of a hyphen.
• Place URLs as close to the root as possible.
• Avoid the following file extensions for HTML pages: “.exe”, “.0” and “.xml” extensions might have problems being indexed.
• If creating automatically, allow the ability to edit URLs from the default format. Limit who can change URLs once they go live.
• Make URLs taxonomy independent. This is especially important for e-commerce sites that might change product taxonomy regularly.

Changing Domains

Nuts.com was moved from NutsOnline.com and traffic tanked because it was a blacklisted domain. All domains have a history. Research it for landmines. Some history can be leveraged. Before you buy, research the history. Before you migrate, test; launch content on the new domain and before you migrate, let it bake for a bit. Don’t change both DNS and server IP address at the same time. When search engines see both changing at the same time, it’s a trigger it has a new owner, which could cause them to reset link counts.

Design Phase

Review Wireframes and Designs

Most wireframe reviews point out only the SEO basics. You need intuition and experience to look for what “might” go wrong. She saw a wireframe of boxes and she inquired about what it was and the plan was to make it JavaScript, which wouldn’t show up to search engines at all. Her intuition pointed her to ask questions. Look for anything that might move. If you see tabs, ask how is this going to be coded? Ask how will this appear when I turn off JavaScript, CSS and cookies. A lot of times developers use wireframes to design, and don’t look at the requirements. Include critical SEO requirements in the wireframe.

Project Documentation

Few SEOs read and contribute to all project documentation. Few project teams involve SEO in the right project documentation.

Development Phase

SEO Code Checks

Be available for questions, and inject yourself to review code before they hook everything together. Few SEOs are technical enough to do code checks. Few companies have SEOs do an SEO code check. Changes are cheaper to make if caught in this phase.

What to look for:

• Turn off JavaScript, CSS, cookies – anything missing?
• Linearize the page – content in the right order?
• Page title tag as spec’d?
• Metadescription as spec’d?
• Images have dimensions?
• Images have ALT text?
• Any display:none?
• Can page load time improvements be made?
• Inline CSS or JavaScript that can be offloaded?

Tools: Use the Web Developmer Toolbar plugin. Use Google Page Speed and Yahoo Y! Slow. They’re all free.

Baseline Metrics

Get the reporting plan together. Figure out what you’ll be monitoring during the launch. The metrics you’re using today probably won’t be the same for the new site or for the transition period.

• Page load time data
• Bot crawl activity
• Webmaster tool data
• Indexation
• Link counts for key pages
• PageRank for key pages

Testing Phase

QA Test Scripts

You don’t want to hunt and peck through testing. They won’t be as formal as test scripts of IT department, but have a methodical approach. Identify all the things that can go wrong and check for them. Look for SEO best practices. Identify all your requirements and how to test for them.

QA Testing

Challenge: SEO QA testing rarely gets enough SEO attention. It’s usually a spot-check, not methodical and thorough. QA testing is like an audit of the site, and many SEOs don’t know how to audit a site. What you should do is get formal about SEO testing and audit the site. Block several hours to test and allow for several iterations.

Post-Launch Phase

Things often look unusual in the SERPs post-launch. Most companies are not monitoring the right SEO metrics. Gather metrics, document the wins and losses. Identify what needs to be changed. Be part of the team, and get your butt out of bed for the 3am call and post-launch testing. Send thank you analytics – find successes and let everyone know who did a good job. She would send it up to management, get the name in front of management, and then send that CMO’s (for example) response back to the developer. Props and support!

Virginia Nussey is the director of content marketing at MobileMonkey. Prior to joining this startup in 2018, Virginia was the operations and content manager at Bruce Clay Inc., having joined the company in 2008 as a writer and blogger.

See Virginia's author page for links to connect on social media.