Hi everybody, and welcome to the recap of Page One Power's panel webinar on Enterprise Technical SEO.
First off, I would like to thank our awesome panelists for sharing their time and insight with us and our audience! Our expert panel featured:
- Tom Anthony, Head of Research & Development at Distilled
- Paul Shapiro, Director of Strategy & Innovation at Catalyst
- Patrick Stox, SEO Specialist at IBM
- and Nicholas Chimonas, Director of R & D at Page One Power.
This was an excellent webinar with interesting discussion and conversation around a variety of topics pertaining to enterprise-level technical SEO.
Note: this recap will paraphrase the conversation, not be a direct transcription. If you're interested in hearing the exact conversation, you can watch the video embeds throughout.
The Overview
The conversation lasted roughly an hour, during which our panel covered a number of topics, challenges, and solutions.
To make the discussion more digestible, I've broken everything down here. Embedded videos are included which begin at the start of each corresponding question (denoted by yellow subheaders).
I've also pulled out particularly interesting quotes or ideas via blocktext, for increased readability. Again, these are not direct quotes.
If you would rather watch the video recording in its entirety, here it is:
Here are the questions our expert panel covered:
- Enterprise sites have thousands if not millions of pages. How do you prioritize and manage technical issues at this scale?
- Working with enterprise clients means a slower implementation cycle. How do you plan accordingly?
- SEO often receives minimal recognition in the corporate structure. How do you fight for budget, sell value upstream, and earn priority?
- Technical SEO requires collaboration across a variety of departments. How do you build interdepartmental collaboration?
- What do you love most about technical SEO?
- How do you handle massive inventory changes causing tons of 404s daily?
- Is it advisable to have large CSS and Javascript for a website in the footer so the page loads faster?
- How do you accurately measure results of changes and show those results to clients?
These questions served as launching points for the discussion, helping guide the conversation rather than control it.
Because the conversation wasn't scripted our panelists were able to include personal anecdotes, unique strategies, and a wealth of real-world information and advice.
Hope you enjoy!
Question One: Enterprise sites have thousands if not millions of pages. How do you prioritize and manage technical issues at this scale?
The discussion begins at 4:05.
Nicholas: Patrick, let's lead off with you.
Prioritization by Impact
Patrick: Okay. I would say hit where you're going to make a decent impact. At that scale for page-by-page, unless it's one of the most important pages it's not going to make much of a difference. But sometimes you have to do the page-by-page to get some small wins and build the trust needed to tackle bigger projects.
For us, it's about tackling different issues with different CMS systems and different business units one at a time so we can build up case studies, and show impact to others. That's the way we go about it.
Nicholas: Do you find you have an easier time getting buy-in if you've proven your case with a smaller subsection of your site? Then you have the firepower to convince the development team to do that at a larger scale?
Patrick: Yeah absolutely.
Nicholas: Paul what are your thoughts on this? We also have a question from the audience if you'd like to answer that. The question is, "How do you optimize for crawl budget for enterprise clients?"
Paul: Let me tackle the main question first.
I think it really comes down to being able to assess the impact of any changes you're going to make.
Once you know what it's going to cost and what it's going to take, it should be easier to prioritize.
That means building out models, forecasting the impact, calculating cost (people, resources, technology, etc.) to implement changes, and from there you should be able to prioritize accordingly. Once you know what it's going to cost and what it's going to take to get there, it should be easier to prioritize.
Crawl Budget
In terms of the crawl budget question, you can check out an article I wrote for Search Engine Land that explains how you can use the PageRank algorithm and calculating that across your website internally, and using that to impact your crawl budget.
Nicholas: Sure. That's an approach that is really neglected quite frequently, trying to get some data behind why you think this change in architecture is going to make the change you expect.
Tom, what are your thoughts on this?
Tying ROI to Technical SEO
Tom: First, I agree with both Patrick and Paul. The correlation of the things they touched on is trying to understand what fixes are going to have the highest ROI.
You need to identify which areas of an enterprise site are actually viable to work on, and understand how quickly things can be implemented.
So you not only need to have a hypothesis of what the required effort will be, but you also need to talk about the payoff and longevity. An example of a bad case is something that will take the devs so long to get to, that by the time the payoff comes around it's no longer worth it.
You need to identify which areas of an enterprise site are actually viable to work on, and understand how quickly things can be implemented.
In terms of Distilled ODN, one of the exciting things from our perspective is having a better hypothesis of impact.
Normally, enterprise sites have a long backlog of technical SEO changes that need some level of prioritization. So we're encouraging people to use ODN for testing to help us better hypothesize the impact of certain changes. It's surprisingly difficult to predict ROI of technical SEO changes on enterprise sites, but ODN allows us to test many different things.
Nicholas: I think that's especially true at this level (enterprise), simple changes might have a larger impact than you expect. And I think on-page SEO matters even more when working on larger sites.
Tom: Absolutely. And Mike King has a great post about technical SEO on Moz.
Nicholas: Yeah Mike's post makes a really good point that many of our SEO tools are behind the game. So if you're just relying on tools and not checking things manually, you could be missing important issues. It's an interesting post and I recommend checking it out.
Question Two: Working with enterprise clients means a slower implementation cycle. How do you plan accordingly?
The discussion for this question starts at 12:50.
Nicholas: Patrick, let's go back to you for this one.
Patrick: Ha, that's a fun question! Sometimes you're waiting, many of the changes I'm waiting on I don't expect to happen this year or even next year in some cases. But there's always plenty of other stuff to do.
But it's not always like that. If you have executive buy-in and team buy-in things can move pretty quickly. It's not always slow.
Nicholas: Yeah, I've experienced both sides of the coin. I think you're absolutely right, and it depends on where you have buy-in (at what level of the organization) that can push it through and make it happen more quickly.
And on the other side—where things are moving slowly and not being implemented—it's because you haven't earned trust or buy-in yet by proving yourself. Once you've proven the importance of your recommendations, it often becomes a faster implementation cycle.
So Paul, what are your thoughts on this?
Implementing Changes Yourself
Paul: Often times you can't do anything about implementation times, it's going to be a slow process. What you can do is implement things yourself, when possible. If you have the opportunity to make the change yourself, it will help speed the process along. Any little thing that you can implement yourself will speed the process along.
If you have a strong tech team you can build trust with developers and engineers by acknowledging that changes on their end may not be substantial, and offering to help where you can. You can get things done quicker by simply knowing what you're doing.
Also, make sure you're clearly communicating the value of these changes and talking to the right people. If you have a strong tech team you can build trust with developers and engineers by acknowledging that changes on their end may not be substantial, and offering to help where you can. You can get things done quicker by simply knowing what you're doing.
Nicholas: Being willing to take the reins and being supportive of the developers and empathetic to their bandwidth helps. It's absolutely true that if you make yourself available you can get access, and often times getting access to make changes yourself is easier than being put on a backlog and making it all the way to the top.
So Tom, can you weigh in here.
Building Relationships with Dev Teams
Tom: I absolutely echo what the other guys said about getting friendly with the devs and getting them on your side.
Just by being present you'll find you can get more done rather than when you're a faceless email coming into their inbox.
From an agency perspective, if you have clients you should go and work from their office. Once you're in their office you can see the dynamics and understand who you need to talk to in order to get things done. In terms of dev teams, see if you can go sit in on their meetings.
Just by being present you'll find you can get more done rather than when you're a faceless email coming into their inbox. We've had consultants go and sit in on meetings, and all of a sudden SEO tickets which previously languished began to bubble up to the top. The consultants didn't even have to say anything—just being a real person who was invested in the outcome of these tickets, made those tickets float to the top.
Then find out what you can do to help the devs. Often there are tickets they find difficult for certain reasons, which doesn't always get communicated back to you. But if you actually go talk to them you can find out why they're struggling and offer help. This will buy you trust with them because they'll appreciate that you've talked with them and recognized their challenges.
Crawl Budget (cont.)
Log analysis is much more accessible than you think, and you can use it to harvest a lot of actionable data. It's something that has sort of fallen by the wayside, but logs are a goldmine.
And going back to the crawl budget stuff, at an enterprise scale log analysis is very helpful for crawl budget. Log analysis is much more accessible than you think, and you can use it to harvest a lot of actionable data. It's something that has sort of fallen by the wayside, but logs are a goldmine.
Nicholas: And it's never been easier with tools like the Screaming Frog Log Analyzer. If you've never done it before, you should give it a shot because you'll be amazed at what you can learn.
Tom: Often the hardest part at the enterprise scale is just convincing someone to give you access to logs. But again, embedding yourself into the appropriate teams will help.
Using ODN to Bypass the Implementation Cycle
Nicholas: And one other thing. With Distilled's ODN, you can bypass the implementation cycle and take charge of making changes yourself. ODN acts like a CDN and allows you to bypass whatever old system is in place.
Tom: Yeah, it deploys similar to a CDN and from a user's perspective they don't see it's there. And it acts almost like a new CMS that just sits on top of everything else.
What was very interesting about this was we expected to have a lot of pushback from dev teams because they would feel a loss of control. But what was surprising was that a lot of dev teams welcomed this change because they were frustrated about old platforms as well. So we (SEOs) were frustrated about our tickets not getting done, and they (devs) were frustrated about not being able to complete them. ODN creates a platform where SEOs can help dev teams and achieve the common goal of making the website as successful as it can be.
Nicholas: Right, it's a win all around.
Note: Nicholas combined questions three and four since question three had already been touched on, and tied in nicely with question four. The responses to the two questions are below.
Question Three: SEO often receives minimal recognition in the corporate structure. How do you fight for budget, sell value upstream, and earn priority?
Question Four: Technical SEO requires collaboration across a variety of departments. How do you build interdepartmental collaboration?
The discussion around these questions starts at 23:30.
Nicholas: Let's lead off with Patrick. I think this is an especially interesting question within the context of IBM.
Training & Collaboration at the Enterprise Level
Patrick: Okay, we got two questions in one. As far as recognition in the corporate structure, we've already talked about tests, case studies, predicting ROI, etc. But I think the big part that's missing there is training the different employees and teams.
Giving teams credit goes a long way. If a team has done great work, then give them credit for it. If they've done a lot of hard work and made the improvements you suggested, it's their win along with yours.
Believe it or not, but in enterprise SEO we're working with far less SEOs per the size of the site, so training is essential. And the good part about training is that it helps you find people that get it, that will become your evangelists.
Giving teams credit goes a long way. If a team has done great work, then give them credit for it. If they've done a lot of hard work and made the improvements you suggested, it's their win along with yours.
If there's something you think will have an impact, don't give up on it. You just have to find someone who will listen and find a way to make sure it's not dying in a backlog.
As far as collaboration, working with teams repeatedly will help build relationships. Even at times you can help teams get budgets or pay out of your own budget to help them get the resources they need to do a project.
Don't Give Up on Projects
Patrick: I keep hearing backlog, backlog, backlog...that happens quite often. Internal or agency, it doesn't matter just keep pushing. If there's something you think will have an impact, don't give up on it. You just have to find someone who will listen and find a way to make sure it's not dying in a backlog.
Nicholas: Yeah, that really drives me nuts when that happens. But I've found more often than not, if I keep pushing I can make it happen. It really is important that you don't give up.
Patrick: Tom made a great point earlier about agency people coming in. When people come in they typically get to meet the right people and have their ear. You can say the same thing five things to someone as an in-house and not get results, but if an agency person comes in and says the same thing suddenly there is more buy-in and you've been corroborated.
Nicholas: Yup, that's very true. I've had people within organizations say, "Thank you. I've been saying the same thing, but we just needed someone from the outside to come say it again".
Thank you for your answers on that one Patrick. I appreciate your transparency. And Paul, let's hear your thoughts on these questions.
Speak the Language
Paul: First of all, I love Tom's tip that he mentioned earlier about taking opportunities to go build face-to-face rapport with clients.
In terms of other things you can do, knowing who you're talking to and speaking their language really helps. For example, if you're talking to a marketing team you're going to want to be talking dollars and cents and how it will affect their job.
Nicholas: For sure, that really is a great tip to go to the client's office. So Tom, what other great tips do you have for us?
Technical SEO Reporting
Tom: One thing we haven't mentioned yet—that touches on question three—is how you do your reporting. SEOs have a tendency to write big reports that intermingle the SEO rationale with the payoffs. One tip for better reporting is don't bury the lead—your email subject line should be the top-level value add. But also, don't just give them a massive Word doc.
You should look at what language the client uses in their annual reports or on their website, and mirror that language in your slide deck. That way, everything your saying links back to them in their own language.
You can create reports as slide decks that presents the main high-level takeaways, making the information very accessible and shareable. Because that big text report isn't going to get read by the management levels, but if you give them a scannable slide deck more people inside the business will be exposed to what you're doing for their business.
Another really important point is one that Paul made—speak their language. You should look at what language the client uses in their annual reports or on their website, and mirror that language in your slide deck. That way, everything your saying links back to them in their own language. And link it to revenue, because that is what the management level cares about.
Highlight Common Goals/Objectives
A more tactical approach is to find out what each departments' goals are. Understanding their objectives will allow you to explain how your changes will help them achieve their goals.
Nicholas: Yeah that's a really good point to understand the goals of the department you're working with and tying your reporting directly into that.
Patrick: That's a great point. Every department will have different goals and you can create a scorecard that will show these various departments how your recommendations will help them meet their personal goals.
Nicholas: Right. And that can provide motivation to move through the implementation cycle.
Paul: There's a great post by Rob Ousbey on the Moz blog that I recommend you read if you're dealing with this issue.
Nicholas: The post David Sottimano wrote that provides a checklist for Junior SEOs is also worth checking out.
Building Versatile Reports
Nicholas: One other thing that you mentioned Tom that is interesting to me is the triangle of reporting. In my mind I've always seen it as three different types of reports you'll put together, including: spreadsheets and data summary, a slide show for the executive level who don't want the nitty-gritty but rather a summary, and then the long written report that explains everything in-depth.
When you're doing reporting, do you typically do all three or do you tailor your reports based on who you're working with?
Tom: What we often do is convert the text-heavy report into a table. So you can have the recommendation in one sentence, and then in columns you can have the technical rationale, what needs to be done, and what the impact might be. This works well because different teams might be interested in different columns and they can skip over the irrelevant information easily.
If you can build one report in such a fashion that it's accessible to multiple teams, you don't have to build multiple different reports.
Nicholas: Yeah, I've certainly found that to be true.
Tom: So if you can build one report in such a fashion that it's accessible to multiple teams, you don't have to build multiple different reports.
Nicholas: Right, that totally makes sense. I think there's always going to be value in putting that information into a slide show with graphs and pictures, but I like to avoid doing that when possible because it's busy work.
Question Five: What do you love most about technical SEO?
The conversation begins at 38:42.
Nicholas: Patrick, let's have you lead us off.
Technical SEO: New Challenges, Creativity, and Measurable Results
Patrick: I love this question! For me, I love that there is always a new problem and stuff I've never seen before. There's always something that I feel like I just wouldn't see anywhere else—there is always something new.
Nicholas: I agree, that's one of the best things about technical SEO, There is rarely a dry moment, there's always a new puzzle to solve.
Paul how about you, what do you love the most?
Paul: You know, technical SEO gets this reputation of being very dry. But I find it to be one of the most creative areas of SEO, because you're dealing with forms of constraint and you're forced to come up with unique solutions and solve problems in interesting ways. So for me, it's really the creativity involved in technical SEO that does it for me.
Nicholas: Sure. It takes a creative, outside-the-box type of thinking to approach technical problems and understand them.
So Tom, what is your favorite thing about technical SEO?
Tom: I'm going to echo the same answer I think—this solving puzzles part. Often, there isn't one right answer or when there is, we can't actually do that solution so we have to find the next best answer. It's that creative thinking to find different solutions.
In technical SEO you can actually see what you've achieved.
Another reason is that it's one of the areas of marketing where you can actually start measuring what your impact is, whereas it's difficult to do that in other areas of marketing. In technical SEO you can actually see what you've achieved.
Nicholas: Sure, and one of the best parts of technical SEO is the testing and experimentation. Playing with the search engines and the machine learning algorithms and trying to figure out what is going to work best is fascinating to me.
Tom: Yeah. And optimizing towards Google's algorithm which as ever-changing means what worked a couple months ago might no longer be the case, so you have to keep learning.
Nicholas: Absolutely. That's a really good set of reasons for why technical SEO is amazing, thank you gentlemen.
Question Six: How do you handle massive inventory changes causing tons of 404s daily?
The discussion begins at the 43:40 mark.
Patrick: So I'm assuming that's ecommerce. I guess I would start with are the products coming back? If they're just 404ing because they're out of inventory but they'll have inventory next week that is a different than if the products are just gone.
In the case of the former I wouldn't let those pages 404, I'd just show they're out of stock. In the case of the latter, if it's a ton you might need to scale up your redirects or prioritize them based on incoming links (both internal and external) to make sure you're not getting a ton of 404s.
Verifying Data
Nicholas: I wonder if this question is coming from someone who is getting a bunch of errors in Webmaster Tools because these are soft 404s. So it could be okay for these to be 404s, but they just shouldn't be soft 404s and you need to make sure your server is sending a proper response.
Tom: This is another reason for the log file analysis stuff, because that is data you can really trust. Sometimes with Webmaster Tools it's really difficult to know if the data is trustworthy. And having a reactionary approach and acting on it can be dangerous, so you want to verify what's actually happening first.
Paul: You may also want to ask why is it 404ing. Is it intentional or not? You probably want to reconfigure things so it's not 404ing when it comes out of stock, and that will depend on whatever CMS you're using.
Nicholas: And it really depends on the situation and whether these are products that are completely gone forever, or are they coming back? That's really the deciding factor.
Question Seven: Is it advisable to have large CSS and JavaScript for a website in the footer so the page loads faster?
The discussion starts at 46:20.
Tom: So there's really two questions there. JavaScript should definitely be in the footer, that's standard best practice for page speed. I've never heard a good case for it (JavaScript) having an impact on SEO.
You should always be verifying what's happening inside Search Console.
The bigger problem with JavaScript files recently is people are using third-party JavaScript files which are sometimes slower, and often blocked by robots.txt. So if you do any sort of render with Google inside Search Console you'll see it's actually being blocked. So you should always be verifying what's happening inside Search Console.
Nicholas: Right. One interesting issue I had with having JavaScript in the head was with Search Console detecting the hreflang code below it. So Search Console said there were zero pages with markup, and it was because of JavaScript being above the hreflang in the head.
So we moved the JavaScript to the footer, and it detected the hreflang and also made the fetch and render work properly as well.
Question Eight: How do you accurately measure results of changes and show those results to clients?
The discussion begins at 48:51.
Tom: There are a whole bunch of different ways to do this. One interesting way is to use Google's CausalImpact library to help you test the impact of a change you've made. Tom referenced this post by Mark Edmondson.
Beyond that, more and more people are starting to use an A/B methodology. Tom referenced this post by Etsy.
Nicholas: Let's hear from Patrick or Paul on this.
Patrick: It's going to depend on the scale, you just need to track what's important. Just make sure you have the data you need to track what you want to do.
Nicholas: Sure. I don't know if you've ever gotten down to the end of the road yourself and not had the data, but that is not a fun place to be in.
Alright let's wrap this up with your final thoughts Paul.
Paul: Sure. First of all, I think the A/B testing methodologies are extremely undervalued in the SEO environment, and if you can figure out a good process for doing that within your organization I highly suggest that.
If that's not feasible, then you're stuck with looking at what changes were made, when were they made, when did search engines pick up on these changes, and what was the impact (traffic went up, conversions improved, etc.).
And then you try to eliminate as many extraneous factors as possible and isolate it to changes you've made. It's not always easy, but you can at least do a decent job of directionally saying this is the impact of a given change.
