Episode Overview: Planning is the most vital phase in the site migration process, as a poorly planned execution can tank your efforts and consume valuable resources and time. Join host ben as he continues Site Migration Week with Searchmetrics’ CMO Doug Bell as they discuss how to best prepare for the pre-launch phase and the resources you need to successfully execute a site migration.
Summary
- Site migrations are resource intensive, requiring leading efforts from teams like dev ops and digital strategies.
- Outsourcing development resources are vital to ensuring teams aren’t overwhelmed by the amount of work needed to successfully migrate your website.
- Phase one of site migration planning should include getting brand details right, such as messaging, packaging and ensuring product taxonomy is uniform so users understand your brand clearly.
- Outdated site navigational features should be reduced or become simpler while refraining from adding more as additional options only further confuses users and complicates the migration process.
GUESTS & RESOURCES
- Doug Bell: Website // LinkedIn
- The Voices of Search Podcast: Email // LinkedIn // Twitter
- Benjamin Shapiro: Website // LinkedIn // Twitter
Ben: Welcome to Site Migration Week on the Voices of Search podcast. I’m your host Benjamin Shapiro, and this week we’re going to publish an episode every day covering a case study that walks you through the steps of an enterprise grid site migration. Joining us for Site Migration Week is Doug Bell, who’s the chief marketing officer at Searchmetrics, which is an SEO and content marketing platform that helps enterprise scale businesses monitor their online presence and make data-driven decisions. Yesterday we talked about why Searchmetrics decided to go through a site migration, and today we’re going to continue our conversation by talking about the prelaunch phase, getting ready for a site migration and understanding who’s doing the implementation. Okay. Here’s the second installment of Site Migration Week with Doug Bell from Searchmetrics. Doug, welcome back to Site Migration Week on the Voices of Search podcast.
Doug: Ben, I have to say, I really questioned whether I would return today given just how really mean you were about the old website, but I’m back. And you’re welcome.
Ben: Doug, we covered a lot of ground yesterday, mostly talking about the reasons for your site migration, and really I’m going to stick to my guns in saying a big portion of that was because I told you that your site sucked for about four years. Finally, you’ve seen the light.
Doug: Let’s talk about a bit of a tip here, which is which consultants to ignore. Ben, I’m going to put you on that list.
Ben: I probably earned that, but you know. Hey. Now I’m the voice of the Voices of Search. So, you’re stuck with me anyway. So, anyway, let’s talk about site migrations. Finally you decided to bite the bullet. Talk to me about what you did to actually plan for a site migration, and how did you figure out who was going to be in charge?
Doug: Okay. Big tip. First one, huge. Get your resources right, folks. Do not underestimate just how resource intensive a site migration is. And so we talked yesterday Ben, about how important our digital strategies group was and that’s all about the analytical and all about the preparation phase. But the other piece I would say is find great partners that can help you with the design, and find great partners that can help you with the build. In our case, we were really lucky to get our hands on an amazing product manager, a guy named Stephen Deeds, based out of our Berlin office who had done much bigger and much more complex websites before we brought him in as a product lead. I also have to give a huge shout out to our new partners also in Berlin based design agency. That’s the key thing. I have to say, as much as we have some design expertise internally and certainly a lot of expertise, it’s about site migrations. We didn’t have product management, we did not have website design expertise in house. And so go get those folks first.
Ben: So when you think about building out your site migration team, it seems like the place you started was figuring out who the captain of the ship was going to be. You started with your product managers, and in your case you went for design and engineering resources next. Am I thinking about this the right way?
Doug: Right. So we assigned two project leads from our digital strategy groups teams, one in the US and then one in Germany. And that was because the Searchmetrics team was split between those two regions. We also, almost the minute we decided to do the project, engaged with our amazing dev ops team at Searchmetrics and our dev ops team is not just responsible for our website. They actually are responsible for the infrastructure for our entire product suite, so really highly qualified, really capable people. Then of course we engaged our own web development resources, and I think the smartest thing we did, Ben, however I will tell you, is that we immediately found development resources that could ride and partner with us, so that we weren’t overwhelming our development resources internally. And that we were able to split the project.
Doug: So new development was occurring with an outsourced resource and then we were running a project in parallel. Big hint here guys. Look at your sites page as you’re heading into one of these migrations, great opportunity to make improvements there. And so we effectively split those development resources into new sites and improving site speed on the old site, and because we used our existing infrastructure and WordPress instance for the new site and existing domain, we were able to actually benefit from that site speed initiative before porting over to the new site.
Ben: So once you figured out who’s going to be on your team and you’re breaking this down, product management, design, engineering, some internal, some external resources, you obviously also had SEO consultants on the digital strategies group as well. What is everyone doing? Walk me through what your site plan was.
Doug: Phase one, over simplified. Ready?
Ben: Go for it.
Doug: Get the messaging positioning, the packaging, get the brand right and all of these things and the product taxonomy had found ourselves in this spot where our platform had developed over the years as had our services offerings and they had gotten very complex, right? So that was an exercise unto itself, making sure that the naming was such that a consumer could easily understand what they were buying. That was really phase one and I’m super simplifying that. As a part of that, the product was a site architecture which closely mirrored our existing site architecture.
Doug: Another thing you want to do is, don’t completely overhaul your site architecture. Great way to really get penalized initially after launching the site by Google. But the key thing we really had there Ben, was that we had started with a design and were able to iterate with that design the user experience with the DSG team and we brought them in strategically. So effectively you have this, I want to call it a push-pull between user experience, which tends to be content lights, right? Lots of space, not necessarily tons and tons of content, and SEO teams tend to want a little bit more of that content. So we very early on, even in the prep phase, were beginning to consider the balance between SEO and user experience.
Ben: One thing that sticks out that you said is that you didn’t want to re-architect the site. Walk me through what you mean by that.
Doug: So without getting into submitting your HTML site map, at the end of the day you have an underlying architecture, and that architecture is driven by your main navigation. Sometimes the utility navigation, but think about that as being the parents and everything else below that as being the child pages. Just to make that idea very, very simple. What you want to be doing is, as much as possible, not messing with those hierarchies. You can deprecate pages certainly, there’s going to be dead content you can get rid of. But for the most part if you are affecting that, don’t add to it. In other words, your main navigation, if it’s going to change, should get simpler and that should be about user experience. Now we certainly did some simplification, but I would say that it was a bit of a wrestling match with our SEO team for good reasons. And I would say Ben, we’re 10 days out from the launch and actually have not experienced any challenges with visibility or user experience on the sites. The stats are good, and I’m happy that we had those quote-unquote arguments early on.
Ben: So what I’m hearing is that you’re not moving the podcast tab to your main navigation until another week or two.
Doug: I don’t know, Ben. After yesterday’s episode where you compared my website to a sick baby, I don’t know.
Ben: In fairness, I did say sick puppy.
Doug: Sick puppy. Thank you, Ben.
Ben: So walk me through some of the technical components that you went through. You’ve got the digital strategies group, you have your engineering resources, you’ve mentioned site speed was something that you wanted to address multiple times. How are you crawling your site, figuring out your inventory, dealing with errors, what’s the process here for making sure that you’re cleaning up the site as much as possible without re-architecting it?
Doug: So the crawls are really important. And so the first crawl you’re doing, and we used our tool and a combination of other tools, but we started with site experience. And what effect we were doing is you’re creating an inventory and you’re also looking for the broken stuff, right? And so errors tend to be all over the place. We actually were surprised by some of the orphan pages we had as an example, and some cloaking we weren’t aware of. So really you’re starting with this inventory and then as you’re building and you’re architecting the site, what you’re doing is you’re trying to understand how Google might regard any changes in architecture. And then you’re just looking for that low hanging fruit, if you will.
Ben: So once you go through and you’ve crawled and inventoried your site, you’ve figured out what’s broken, what are your next steps?
Doug: I think the thing I failed to mention that was almost as important as treating this like a product is that we were not going to tackle this as if it were a waterfall. We were tackling this very much as an agile project, right? And so to do that you’re not necessarily doing a crawl then stopping, right? You’ve got another crawl that’s going to be coming up. But the adjunct, the thing that couples really well with that crawl is actually a content audit. And there are tools out there that’ll help you do this. You don’t necessarily have to go buy a mega platform to be able to tackle it. You can actually do this on your own. There are tools within search console that will help you do this. But the key thing was to look at the page that we were looking at updating or any type of architectural changes that we were making, and to audit that content.
Doug: And of course since we have, like I said, I’ve got this Ferrari, Ben. So in some cases, especially our product pages and our digital strategies group landing pages, we use content experience. But for the most part what we were saying is how is our content meeting the needs of our audience or users searching for, versus what are they getting when they land on those pages. So, that’s the quick sprint content of it. We had considered actually doing the whole site audit and content audit and yeah, shout out towards ESG folks, they were very good at convincing us that it was much more about addressing the content that we currently are dealing with when we roll on to the site as opposed to the entire site itself.
Ben: So you’ve gone through and you’ve taken a look at your underlying site infrastructure, you’re not re-architecting, you’re finding the errors, you look through your content. What are some of the other steps that you’re going through before you really begin the development phase of your migration?
Doug: You know, it sounds like really basic blocking and tackling, but take a look at the underlying hosting infrastructure. And make sure that you’re optimized for speed firstly. There’s this idea of C blocks, which we don’t need to get into necessarily, but make sure you’re in a good neighborhood from a hosting standpoint as well. You’d be shocked at how Google can penalize you for that. And we actually at one point shared the AWS instance for our platform, so our product platform with the website. Which again, Ferrari. But at the same time our flexibility as a team was affected because we had to get the attention of our dev ops team who was supporting this entire platform. And so one of the decisions we made early, and it never occurred for us to make this decision with auto product management and TSG team, was to actually separate out that instance. Boy that gave us all sorts of freedom and flexibility. Also in terms of ability to problem solve from a dead ops standpoint, tons of flexibility there as well.
Ben: Talk to me about some of the analytics that you’re using and how are you trying to create benchmarks so you can understand the before, so you have something to compare to the after.
Doug: You’re taking snapshots, Ben, that’s the best way I can put it. We used a combination of GA and our own software to take those snapshots. It was slightly different depending on the phase. We had situations where we scoped in and out of certain portions of the website. As an example, our phase one was homepage, product section, services section, and we had considered scoping in our knowledge center and ultimately it’s a huge content hub for us. And what we ultimately decided to do was to de-scope it if you will. And so as we were going quarter to quarter and taking a look at this project, we would benchmark and literally we would take elec snapshots, take our own website and we would chart where we were. Analytics in our own product, obviously have historical data. It’s not because we’re going to lose that data, but it was much more about saying here’s the point in time or measuring performance and then comparing post-launch on that.
Doug: It also helped us find a whole lot of spots where we needed to improve that. Especially on the CRO side of things. So you’re looking at things like visits to click through rate, click through rate to offer acceptance. Just an example. And as we were looking at our product pages and services pages, we were using our conversion rates on those pages as the primary benchmark after traffic, and after other typical metrics like time on site, bounce rate, x-ray, et cetera. So we were primary looking at our CRO conversion rates if you will, pre and post launch.
Ben: What I’m hearing from you is that this phase, before you actually start your development, is very much centered around collecting inventory. You’re trying to understand what you have in terms of a site structure problem, what you have in terms of content. What you have in terms of your business performance. What’d you have in terms of opportunities to optimize your hosting. You’re really just looking at the lay of the land and figuring out what are the parts of your sites that are working, so you could figure out where you need to invest your time in developing new solutions.
Doug: That’s right, Ben. And this is also that gut check phase as well, which is are you appropriately resourced and quite often, luckily for us, we were. And again we could flex out to our own strategies group when we felt like we had resource challenges. But this is usually the phase where you find those gaps. And I would say just a huge tip also, everything you estimate at 20 percent from a time standpoint and 20 percent from a resource standpoint. We did that and frankly we were still caught by surprise in the pre-launch phase. I would stick to the site speed portion as being somewhat surprising to us, Ben, in terms of where we needed more resources.
Ben: So lots of work to be done before you actually start the development phase of your site migration. This is not a type of project where you sit down and just start coding on your own. And we’re going to talk a little bit more about the actual development phase of a site migration, in tomorrow’s episode. So that wraps up this episode of the Voices of Search podcast. Thanks for listening to my conversation with Doug Bell, CMO of Searchmetrics. We’d love to continue the conversation with you, so if you’re interested in contacting Doug, you can find a link to his LinkedIn profile in our show notes.
Ben: You can contact him on Twitter where his handle is market advocate M-A-R-K-E-T A-D-V-O-C-A-T-E. Or you can visit his company’s website which is searchmetrics.com. Just one more link in our show notes that I’d like to tell you about. If you didn’t have a chance to take notes while you were listening to this podcast, head over to voicesofsearch.com where we have summaries of all of our episodes, contact information for our guests. You can send us your topic suggestions, your SEO questions, or you can even apply to be a guest speaker on the Voices of Search podcast.
Ben: Of course, you can always reach us on social media. Our show’s handle is Voices of Search, or you can reach out to me personally. My handle is Ben J. Shap, B-E-N J. S-H-A-P. And if you haven’t subscribed yet and you want a daily stream of SEO and content marketing insights in your podcast feed, in addition to the third part of my conversation with Doug Bell, CMO of Searchmetrics, where we talk about the development phase and how Searchmetrics has boosted site speed through their site migration. We’re going to publish an episode every day during the work week, so hit the subscribe button in your podcast app and check back in your feed tomorrow morning. All right. That’s it for today, but until next time, remember, the answers are always in the data.