Advanced and Technical SEO - SEMPO

Good afternoon everybody and welcome to the March SenPo Hangout. Present, we have Justin, who is the chair of the SenPo Education Committee. We have Avner, who's also on the Education Committee. We have Brooke, who is basically the glue that holds SenPo together. And then we have our panel. We have Barry Adams. who is at SEO Polymathist. We have Christine Schackinger, who is at Sites Without Walls, and unfortunately doesn't really have any visual at the moment. And then we have Steve Plunkett, who is a senior search scientist over at Rockfish. I'm Simon Heseltine. I'm also on the Education Committee. And we're going to just jump in and get started with some questions. So whenever I start, Working with a new site, one of the things that I do is jump in there and do that technical audit. I've got to see where the site currently sits, what the issues are, what really needs the most work. So we'll start with you, Barry. Where do you dive in? How do you jump in? What's kind of like that process of yours? If you'll give us the secret sauce, that'd be fantastic.

Secret sauce. I don't really have any secret sauce. It's just a lot of hard work, really, isn't it? You start at the typical stuff. Check index levels. Check crawl errors in Google Search Console. I mean, I think most people like me who do a lot of audits, we have an Excel sheet that we just use as trigger points for us to go look at websites. Invariably, we'll get off on a tangent because we find something interesting and then we keep digging into that. until we find the root cause of what it is and then realize we've massively run out of time on that particular audit and still have 2/3 of it to do. Or maybe that's just me. I don't know. But yeah, you start with index and you work your way up from there. Generally speaking, most technical SEO issues are either about Google being able to crawl the website properly or not. And when it can crawl it, if it indexes the right pages or not. And nearly all technical issues will relate to one of those 2 aspects. So you look at crawling and you look at indexing. And then from there, like I said, the rabbit hole just leads all the way down really.

Okay. Christine?

She should remember to unmute her microphone.

What do I do? Yeah. Unmuting would be good. You're asking me the same thing, what I would do first when I jump in?

Yep.

Basically, when I jump into a site, the first thing I do is a Screaming Frog crawl on the pages to get an overview of where some of the issues might lie. And then I jump into Google Analytics and look for anomalies that kind of point out where maybe there's something that's not obvious. And then I kind of work from there. So basically, looking— like one site, 10 million pages, didn't have any canonicals. It turns out the dev put it in wrong. Right, so that was like the first thing we fixed. But that's really obvious on Screaming Frog, where if I was going page by page, I might not notice that. So I do the high overview first, and then I work my way down through Analytics Console and then page by page.

Okay, okay. So Steve, any other kinds of tools that you use as part of that initial audit?

Probably number one, a Google search. Go do a Google search for them, see what they've got in the Knowledge Graph. Use Rich Snippets tool on their website immediately. Just like Christine, I'm going to use Screaming Frog. I'm also going to do a link profile using Majestic where I can get that out and then try to get access to Google Analytics and Google Webmaster Tools from the client side to get the data to find out what's been going on before I start making assumptions.

OK. Yeah, I don't think without Google Search Console and Analytics you could actually do a proper audit.

Yeah.

Search Console in itself is a starting point for practically all your discoveries in one way, shape, or form. And like Steve said, you do a Google search and see how the website is actually being shown in search results. It can also lead to all kinds of interesting findings. I, of course, Screaming Frog is, well, everybody's go-to tool, I suppose. I also like to use a cloud-based crawling tool like DeepCrawl for the larger websites. Also, it does some pre-analysis for me and still allows me to extract a full list of URLs. that it crawls. So it has some advantages over Screaming Frog. It has some disadvantages as well, that you don't get that raw crawl data in as much granularity as Screaming Frog gives you, which I really, really appreciate about Screaming Frog. So I tend to use them in conjunction a bit.

Yeah, and the one that—

go ahead, Kristin.

I was just going to say another tool I like to use in addition is WebPageTest, to get an idea of the waterfall, how the document's loading. What pixels they're using, how many resource calls they're making, time on first page.

What's the longest you've ever seen, Kristin? The longest page load on WebPageTest?

Oh, right now I have a client that has an 80-second page load.

129 seconds the other day I tested a site.

Oh wow.

I'm serious.

129 seconds. I mean, I just wanted to slam my head against the keyboard until something broke. Hopefully my skull.

Alan Bleiwais and I had a contest one day on Facebook of—

Oh, he won that, didn't he? Yeah, he won that. 300 seconds or something crazy like that?

No, this is resource calls. So I had 499, and he said he hadn't seen higher than that. And then an hour later, he had 999.

499? Oh my God. That's just— Yeah.

It's amazing how many people don't realize how much that page speed can impact them. Using the actual Google PageSpeed tool, The worst I'd seen was a 6 out of 100, and then I saw somebody post one last week that was actually a 0 out of 100.

How do you do that?

I didn't think it was possible for that to actually happen. But the great thing about that web page— the web page tool you're talking about, Christine, that's something that was actually developed within AOL, and it was developed as open source, so anybody could work with it. But it's now actually— I believe it's actually under Google. Google actually maintains that WebPagetest tool.

Really? See, I didn't know that.

Learn something new every day.

Which is why you have the option to log in with Google+ on it, but not with any other social network.

That would make sense.

So webpagetest.org, it's a good tool for actually looking at that waterfall analysis and looking at that type of issue.

It surprises me how few web developers actually know that a tool like webpagetest.org exists, let alone that they use it.

Yeah. So one thing that I've been asked is to just throw out the names of the tools that you guys have mentioned again. Screaming Frog, Majestic, Deep Crawl. One thing that you haven't mentioned, and it's It's the equivalent of Google Webmaster Console. How about Bing Webmaster Tools? Do you guys not look at that?

I'm sorry, Simon. I live in Europe where in worst-case scenario Google has a 90% market share. And that's only in the UK. Every other country it's 95% plus. Bing, as far as I'm concerned, might as well not exist.

Sorry.

I think you have to look at Bing Webmaster Tools just because you've got to correlate the data. And if you see something that happens in Bing Webmaster Tools at the same time it's an issue in Google, then you know you've got to address it.

Steve—

oh, go ahead. Go ahead, Barry.

Do you come across a lot of those issues where Something is reported in Search Console but not in Bing Webmaster Tools or vice versa?

Say again?

Do you have a lot of issues where you see something being reported, for example, in Google Search Console but not in Bing Webmaster Tools or vice versa?

I think it's more of I see stuff coming across where I don't see it being picked up in Google and it gets picked up in Bing, or where I see that both Bing Webmaster Tools and Google Webmaster Tools pick it up. both, and that's kind of why it's more important to focus on that first. So it's a good—

I will tell you one—

—assessment tool, I think. Shout out to Domain Trust.

I will tell you one that's different, Barry.

Yes, I hope.

So one way that's different, in Google, they tell you if they detect malware on your page. In Bing, they tell you if you're linking to a page that has malware on it. So it does go a little bit deeper on that malware side.

I might have to actually start looking into that. Not that I need more data. If anything, I need less data nowadays because you just get drowned in this stuff.

Yeah. So I actually had a client—

Does anyone have— sorry.

So go ahead, Avni.

Does anyone have any experience with Yandex's Webmaster Tools?

Sorry. I should, but I don't. I'm a bit of an old school that I stick with what I know. And I haven't yet had to order the website that wanted to get any meaningful presence in Russia. So no, I haven't played with it yet.

OK. Well, let's jump on to— let's start with Steve on this one. What is the strangest SEO issue you've actually come across? And how did you resolve this?

Oh, 147 domain names, all 301'd to the same exact website, which all had Google Webmaster Tools accounts verified for www and not www.

And how'd you fix that?

It was kind of like— I think through the entire engagement, we really didn't get it. We really never got a resolution to it.

Mm-hmm.

Because they never really took them all out. But at that point, we just started to take— they had a lot of content. And the problem was is you had basically a list of locations, and it would resolve for every single one of those domains. So they had a database backend where it was a 301 direct with the domain name. But if you put in that domain name/location/state/city, /zip code, it would still show up and still resolve in their CMS. Anybody get that one? Or is that still just whack?

That is a bit whack, yeah.

You said what's the worst thing, and that was kind of the worst thing. I still think about it, it still boggles the mind because you're just like, what is this? Why did Hey guys, how many do we need?

I mean, that is absolutely something that happens everywhere. We come across these issues that nobody else has necessarily seen before. I had one several years ago where a site, their pages were indexing 7 days to the week. So it's 7 days after the articles were actually launched. They wouldn't show up. They'd only show up in Google News. They would not show up in Google Search. 7 days later, up they showed. And it actually ended up that it was a bug in Google. And by talking to some Google engineers, we got that fixed on their side. It wasn't anything we were doing. And we were pulling our hair out trying to get that fixed. So Barry, what have you come across that's had you pulling your hair out?

Yeah, quite a lot of them. As you can see, I don't have an awful lot of hair left. You come across these weird things all the time. I mean, some of the stuff is just, you know, you come across Wix-built websites that generate their content entirely through JavaScript and then people wonder why they don't get indexed.

Hmm.

I came across an interesting one recently where the staging environment was actually being indexed by Google. any visit to it through and redirected to the actual proper live site even with the Googlebot user agent. But it turned out that that redirect was a JavaScript redirect. So Google's crawlers wouldn't necessarily use it all the time.

Mm-hmm.

So that was a bit of an odd one. One I came across which bothered me for a little bit until I dug a bit deeper was that the sitemap that was supplied had zero-indexed URLs. So they gave like 6,000 URLs in the sitemap zero-indexed. And I crawled the sitemap and they all looked fine. They all gave 200 OK status codes. And then I took that Screaming Frog export and checked the canonicals against the URLs. And that's what the problem was. The canonicals all had the trailing slash, whereas the URLs submitted to the sitemap did not. And they didn't 301 redirect with the trailing slash. So that's one of those things that will stump you until suddenly you have this aha moment. And you realize that, ah, that's what it is. You know, every site audit has something interesting like that that shows up. If it doesn't, I get worried that I'm not looking deep enough.

Yeah, exactly.

Yeah. So Christine, how about you?

Oh, I think every audit has had something odd or bizarre in it. I had one client that had 40 million zero-second visits from 40 users. I had another that had the first pure spam penalty plus 3 others. Actually, the Google guys even were surprised that it had 4 manual penalties and was still floating. It was still alive with 30 million visits a month because it was a big brand.

Wow.

Yeah. I think one of the most fun ones is I got a client out of a Demand Media contract. Demand Media was own their subdomain for 2 years after they even decided to not work with them anymore. They would still be able to put content on it. And we found Demand Media was doing some interesting things and was able to get on the phone with their lawyers and get them to drop the contract within 30 days.

Okay.

So stay with you, Christine. I mean, what do you think are like the most common technical SEO issues that often go undiagnosed.

I think the biggest issue today that I see is people think that there's infinite bandwidth, so there's infinite page load. I see sites nowadays that are 15 megabytes a page, 20 megabytes a page. Just 10 years ago, you wouldn't have a page over 100K, right? So the— and a lot of that's dealing with advertising. There's not advertising strategy, there's just put more ads on a page. So one of the biggest things we usually work with is getting them to get their page speeds down because they're not talking like 6 or 8 seconds, we're talking like 14 seconds, 20 seconds, 30 seconds per page load because of the advertising and because of the images. That's the other biggest mistake I see. Nobody tells the image people that they have to compress before upload, and then they try to change the size and they think that compresses, and then they'll have images on a page that are 1 and 2 megabytes big and it's 125, you know, width image and they're like, well, we compressed it. It's like, well, no, you changed the size. You didn't compress it. So I think that's like the largest issue I see right now. It's on every site. There's a lot of sites that have other issues, but I think that's the main one.

What's the most ads blocks you've ever seen on a single web page, Kristine? I think I might be able to beat you on that one.

I think you can probably beat me. The one I've been dealing with recently had 10 to 12. But they were adding about 15 seconds of download time.

Yeah. I had one that had 90. 9-0. 90.

Oh my God. What was the page load on that?

You know what? I don't think I even tested it. I just looked at the 90 assets and just told them to start over, really. I don't think they even wanted to test them.

My favorite one is the, the company that loves infinite scroll on everything. And I don't mean Infinite with a cap, I mean just infinite scroll. So like after their story and comments, they would put infinite scroll with heavy imagery and it would just go forever. And I'm like, nobody's reading this, guys, just take it off. But they didn't.

It's still there.

Yeah, I'm seeing a lot more brands actually doing that these days. They're doing the infinite scroll on their main river on the homepage. But then they're also doing the article infinite scroll as well. So if you go to an individual article, once you scroll down past the comments, you're suddenly on the next article. Have you guys been seeing that happening more, and are people implementing that right?

I'm okay with that as long as you said it's implemented right. I work with a few publishing clients who do that, and it's okay as long as there's an HTML5 update of the URL done, and then you can always use it. URL to find that direct article link. If you do that, it's fine. And it does have some benefits because when I see myself using those websites from a user point of view, you do keep scrolling if the article is interesting. You do keep reading. But there are a lot of ways you can implement that that don't necessarily work well for SEO. And they tend to be the easy way to implement things or the way that a web developer who is only just beginning to experiment with these technologies would implement them. So you will need to do a lot of sanity checking on that before you can give the green light from an SEO perspective.

The other issue I see on those is implementation of Google Analytics tagging to measure the scrolls. It's often incorrect. And the one company I was working with was doing beacon tracking. So every so many seconds, it would ping again. and scrolls, and they were getting— they thought they were getting 19 pages per Facebook visit because of the— I've never seen an average over 3, right?

Yeah.

But that's because of the way they were doing the tracking. So that's very complicated. I will also say I've worked with 4 major publishers, 2 that did infinite and 2 that didn't. In Search Console, impressions and things of that nature go way down on infinite scroll, and I don't know if it's because Search Console is not measuring it properly. Or if it's an issue with the SEO values. But they don't seem to do as well, and they do have much lower organic presence. The one site I know that does infinite scroll on everything, their organic traffic is about 8%, and they don't show up in the top 5 for much of anything. And they do do it quote-unquote correctly, but I think you have to cap infinite scroll too. You can't just let it go forever. No, there's no reason to have 100 of them. One news site I saw had 176 articles loaded in their infinite scroll. I was like, who's looking at 176 articles? If you want to do like 2 or 3 scrolls, I get it, you know, 10, 20 articles. But when you get to 50, 60, nobody's reading that.

Yeah. So Steve, let's jump on to you. So one of the things Barry talked about was, you know, when people implement sites in JavaScript or in AJAX, and they can't be crawled. Is that something you've been encountering? I mean, there's conflicting things that come out from time to time about exactly how much Google can actually see, how much Google can read. What are your thoughts on that? And you're muted, Steve.

I think the thing is, is you look at rich snippets.

Mm-hmm.

I think the Rich Snippets Testing Tool will show you what is not working and what isn't. I think along with the JavaScript, but a lot of times, like, I use Blogger instead of WordPress, believe it or not. I use actually Google's product for blogging. And like, my page speed, I can't get it up because of things that are in Blogger.

Mm-hmm.

Because they can't read Blogger widgets because they're written in JavaScript. For some reason. But why did they create them? I think it's different depending on what it is. A lot of times, some companies have these. I don't think we're seeing that much AJAX problems anymore, that many crawling problems anymore. I think that was 2 to 3 years ago. And I haven't really seen anybody that's built anything that isn't in Python that doesn't render correctly anymore.

Okay.

Does that make sense?

Well, I would say yes, except I actually did sit down with a client 2 months ago who had completely destroyed their site with their Ajax implementation. So it is still out there that there are people still having issues. Barry, you had something to say?

Yeah. I think what Steve did, the crawling is becoming less and less of an issue. In the previous years with my larger clients, you'd do very hard to try and preserve crawl budget. And Google would sort of support that with Google Search Console messages when they find large numbers of URLs on the website. I get fewer and fewer of those even on the really, really large websites because I do think Google has gotten a bit more lenient about that. I still think you've got to do your best to preserve crawl budget to a large extent. Low speed being a big issue there. You know, making sure you block your faster navigation or at least guide access to that in meaningful ways. But, you know, I think these recent infrastructure updates that Google have been doing behind the scenes, and we don't even know half of all the ones they have actually rolled out, have made it easier for them to come to grips with those sorts of large-scale websites because I think they realize they sort of have to. They can't just always put the burden on webmasters and SEOs to try and fix this problem for them. They kind of have to develop some intelligent systems themselves to come to grips with these websites because they do want to see what's happening there. They do want to understand if there's valuable content in there that can be ranked for interesting queries. And just always putting the burden on the webmaster or SEO who joins that website You know, we all know, we've all worked with big companies. It can take years to even affect a small minor change, let alone make some major drastic improvements on the website that needs a massive overhaul. So technical SEO, you know, the crawl side of things has gotten a little bit easier, but then, you know, other stuff has gotten harder. Especially with larger website setups, dealing with CDNs and different servers and That sort of stuff, so it keeps the industry interesting, I suppose.

Christine, to follow up from what Barry was just talking about, how do you make that sale on implementing some of the technical SEO aspects that may not necessarily have been tried out too much at other places, but they're things that you know that will work or may work? How do you make that sale to the clients?

I think each one is always case-specific. So a recent client, I had to tell them to remove some of their ad spots, but once we did and got their page loads faster, they would get more clients, right? They'd get more users. So their users have gone up almost 80%. You know, so we went from like 150,000 to 200,000 a day to 250,000 to 400,000 a day. So the ad spots they have now are making the same money that those other ones were, but now a lot more people are seeing their pages. But a lot of times you have to get them just to trust in the process, and that's hard. So we do audit support, otherwise things don't get implemented. I gave one client a 250-page audit, basically telling them they had to redo their whole website, and they did nothing. So I think without audit support, it's really hard to sell it. I think with audit support, when you're working with a team day to day and you know their blocks, and their friction, then you can help them understand how it's going to help them. And also make sure to be very good about respecting the devs' time. So I don't make like— I don't give them a suggestion that's going to be a heavy dev lift that doesn't necessarily have a heavy payback with it. So I try to make sure the devs know that they're respected and that their time's respected. And if you can get the devs on your side, then pretty much then everything gets implemented that needs to be implemented. Because they're the ones who have to do the work.

Yeah. Steve?

Well, I think it's kind of one of those things of you go into how things work and, you know, is the client going to do— what's the low-hanging fruit? What can they fix real quick? What's the format of their website dev? Do they have a really high-end CMS? Are they using WordPress? What's the format? What can you do quickly for the client to make the most inroads and progress to where they'll actually start adopting what you're talking about and actually start to get after the audit?

Okay. Avner, you had a question.

Yeah, just unmuted myself. I was wanting to ask you guys what you What do you think about Google's new suggestion to have accelerated mobile pages, a.k.a. AMPs? Will that take off? Will we all have to implement that?

Short answer, yes.

Well, but here's the thing. It's just real-world practice, okay? I am— let's see, how can I say this? I'm working for a particular company that has retail locations, and I'm going to the retail location, and unless I post on social media, the AMP cart isn't triggered for my notification that something is on sale at that location. You follow me so far? Okay, so the other option is to put beacons at the checkout, but then again, it's still triggering the AMP page notification on my mobile device after I've already checked out. So now what we're looking at is how can we trigger an AMP page based on a contact entering a space for RFID or Wi-Fi within the location and getting a signal from that to trigger the AMP page. page with the Google Now card prior to walking in the retail establishment instead of the only way we can really get them to see the AMP card is after they've made a purchase or after they're leaving the location if they tweeted on social media. Was that too much?

That's an interesting use case actually.

That's what I'm working on in the past week, so that's real-world stuff right there, what's going on. Yes, they are being used. I think they're going to be used even more. I think we're going to cross a barrier to where we've got retail establishment in the contact list of our mobile devices. That's the next step.

I'm just— sorry, did I lose you guys?

No, we're still there.

Oh, okay. I just wanted to throw in a quick note though on AMP. I just worked with a client that implemented it. When you're doing your analytics, Google advises you set up a second property ID for it because what it does is it can duplicate the user. So you can wind up with one user showing up 2 and 3 times. Also, other things can trigger it like CDNs. So you don't want it to be in your main analytics because it can really throw off your numbers.

Okay. Barry, do you have anything to add?

That's one of those integration nightmares. I think I always said— we also said this in the chat— the future of SEO and I think the web in general is about integrating with the big platforms like Google, Facebook, and Apple News to a certain extent. They're the gatekeepers. They've got all the keys. They have the audience. We need to tap into them. So we're sort of obliged to dance to their tunes anyway. AMP is one of the bigger moves recently where basically Google is asking us to generate old-school 1995 versions of web pages so they can serve them really quickly to mobile users. Facebook Instant Articles is the exact same thing. Apple News is the exact same thing, just with their own different formats and different schemas. In the very near future, we are going to have integration with e-commerce platforms on a much more advanced level where, for example, on Instagram you'll be able to buy exactly what someone is wearing and showing off without actually having to leave Instagram. Again, that will require a certain level of integration. with that platform. The old adage that, you know, you always want to have your own website because that's the only part of the web you own yourself, control yourself, that remains still true. The problem is that it's going to become harder and harder to build audiences to come to your website. And instead, you're going to have to integrate with these other platforms to get that audience to come to you instead through those platforms. And that's going to be the big challenge moving forward, I feel.

Okay. Okay. So really simple question now. What are the best CMSs, the worst CMSs out there to work with from an SEO perspective? Since you're up, Barry.

Anything built on ASP.NET is by its very nature shite. Sorry for the language. This is not entirely true. I have to caveat that. I know some really good .NET developers who build excellent websites. The thing is, the vast majority of web developers on .NET, I can't even with a good conscience call them web developers because they do drag-and-drop web building. It's not proper coding even. And you end up with the most horrendous— well, I can't even call them websites, you know, with a straight face. You'll find that the more complicated the language and the more it demands of the coder, the better the end result, generally speaking. You know, it pretty much comes to itself. Every CMS has its own use case. WordPress works well for brochure websites but doesn't do everything as well, especially if you scale it up. Magento is okay for e-commerce but again has a lot of built-in risks that a good developer will need to beat out of it before it can actually become useful. Every platform has its pros and its cons. Recently I came across a website built on Umbraco which actually did really, really well despite the fact that it's a .NET system. But then that was the end result of several iterations and several years of improvements being implemented on it. So in the end, I try to be CMS agnostic because I know that every CMS has its pros and its cons. In practice, if it's a .NET CMS, I tend to be a bit more wary than if it's a PHP or LAMP stack.

I think that issue, Barry, comes from the difference in— and Steve could probably talk to this— but the type of mind you need to code. So PHP is a different type of coding than development in .NET. So if you're not an experienced developer as opposed to a line coder, .NET is probably not what you should be working in. Whereas— but you can do a lot more with that. But with PHP, it's a It comes from a different mindset.

I think it's also about what it's been designed for. I mean, .NET is an extrapolation of the code that people use to build Windows software. And that makes it inherently less optimal for building interactive online platforms like websites.

I'd actually— I'd have to disagree with you just because I worked in Microsoft shops for 14 years. I didn't actually develop .NET. But I didn't see any inferior product come out because of .NET. It was the coders. The coder had to be a full on-scale developer and not someone who just knew how to throw things together with, like you said, text.

That's more or less my point there, that PHP requires more from a coder to actually start making it useful and building websites with it, whereas .NET makes it too easy.

Okay. So Steve, does your head drop when you hear the word Drupal?

Do what?

Does your head drop when you hear the word Drupal?

Well, no. Drupal, I mean, any kind of open source CMS, okay, WordPress would be more— WordPress scares me more than Drupal. Okay, you can lock Drupal down. There aren't as many people trying to hack Drupal as there are WordPress. So it's still a CMS, you know. I prefer Kenico. It's way more expensive, but there's a lot of modules built on it that can be used for very large applications for very large organizations. So it just depends on your scale. If you're out there trying to find a free CMS, well, then you're going to spend 3 times as much on security as you are on coding. Whereas if you get a locked-down CMS that already has most of the bugs worked out of it, then you don't really have to spend a bunch most of your time on security and you're spending time on development. That kind of help what you were looking for, Simon?

Yeah, I mean, is it worthwhile going to something like WordPress VIP where the security is locked down more but you don't necessarily have the control over your own sitemaps?

Well, why don't you go to Blogger where Google does your IT? admin and security. You don't have to worry about it at all.

But then you don't own the content anymore.

Well, but do you really own anything once it's on the web?

That is a good point.

Technically it's still yours.

But, you know, I just— it depends. WordPress You know, 10 million users hacked on WordPress. That's a problem. How many users hacked on Blogger? Never hear that story, do you? But then how many people use Blogger compared to WordPress? And then now we see why nobody ever hacks Blogger.

Mac versus PC.

Yep. Right, Mac versus PC, PlayStation versus Xbox One.

PC all the way.

Hey, I'm on a Mac now. I was just going to add to that. The CMS— I've never seen a CMS at an enterprise level that's not some sort of bastardization of the original. So a lot of times it depends on how good your dev team is, right, and what they can do with the product.

I will say there was a major publishing site that I was working with that up until last year was working on a Frankensteined version of 2005 So yeah, you're quite right with that, Christine. That does happen.

I think in the past I used to think that, you know, not using a CMS was just idiotic because why would you want to reinvent the wheel and get something built bespoke? Now as I've become more experienced and seasoned in these things and learned the hard way, as we all do, I suppose. My thinking has evolved to such an extent that I now actually feel that when a business reaches a certain scale and a website reaches a certain scale, you should actually get something built bespoke.

Yes.

To make sure it does everything you want it to do exactly how you want to do it. And you can just, you know, fine-tune it to an extent that you can't ever do with CMSs because that particular development force have come from a certain philosophy and a perspective that will not ever fit with your website 100%. These CMSs always are, you know, jacks of all trades to a certain extent. And after a while, you will always require for large enough websites a very specialist tool that does something exactly how you want to do it. And that means you have to have it bespoke built.

I 100% agree with what Barry's saying. And I've seen that at an enterprise level where they try to use like Drupal when they far exceeded its uses, right, or its abilities. I think when you get to a certain level, a customized built CMS is always a better option. It's just more dev and money, but at that point you should have the dev and money.

Yeah, absolutely.

I'd just like to point out, I don't know if it's that relevant for our audience, but you guys are talking totally enterprise, and I mean, I have some SMB clients And they're using stuff like Wix and—

Oh God, no.

Yeah, so first of all—

Squarespace. Hang on. Go to Wix.

What?

You know what though, Google recommends those 2 on its recommended CMS site, which I find ironic. They took it out. Yeah, they have a page and I'd have to remember where it was, but they actually recommend like CMSs to use and they do put Wix and Squarespace on there. And this was after They took Wix out of the index.

Yeah.

Which I thought was ironic.

This is already, I think, business stuff that has to do with NASDAQ shares and indexes, etc.

Okay, so I'm going to jump on now and ask a question that came in over the Q&A. Also, like, if anybody out there wants to ask any questions, feel free to jump in on the Q&A and ask the questions there. Throw the questions out on Twitter. We're monitoring all of those. So the question I want to ask that came across was about schema.org and markup. Steve, you talked about it a little bit earlier. Is it still a worthwhile accelerating tactic? Is it still worthwhile doing? Or are you just kind of giving everything away to Google? So you do a search these days for a flight landing. You no longer go to the airline's page. It's there in Google. The instant answer is there for you. So a lot of people have that reticence about giving all the data away and losing that traffic to their actual site. But do you want to talk about the benefits and what some of the issues are? We'll start with you, Steve.

I think the thing is, is you've got to realize that airplane landing time or scheduling time came From the airline's website, so if you're the airline, you want your flights to show up everywhere. So I would I would see and I mean God golly it's it's this is like what do I wake up every day and start to work on schema? I mean honestly what there there I think it's a God gold rush land rush um what are the terms we used to I mean that was because Right now, last week, 2 weeks ago, I was working on a schema that didn't exist for a large global manufacturer that makes something that— I can't say who it is, but they make something that people use every single day. They have things that are attached to their product, and there was no schema for the things that attach to the product. So we created that, and that manufacturer is moving forward using that schema. And that's going to affect everything from e-commerce to— how can I say stuff without giving it away? Just everything. I mean, that's— and so the big part is, is if you're not doing schema, what are you doing?

Yep.

I think we now live in an object-oriented world where a thing has a height, a weight, a volume, a price, a quantity, a container, and, you know, that's really— it doesn't matter how big or how small your item is, you know. You've got a shoe. What color is the shoe? What size is the shoe? Does the shoe light up? Does it have laces? You know, what— does it have RFID on it? Does it have a fitness thing that goes to your watch? You know, I mean, that's kind of the thing with stuff that schema is just, to me, just— that's the opportunity for me and brands.

Yeah. I think Steve hits the nail on the head there. I think we as SEOs have too narrow a perspective on schema, just purely looking at it from the web and specifically search point of view. But what schema actually does is make data useful across all platforms because it allows for interoperability and transition between platforms. This is something XML as a language, as a markup language, has been promising to do and has done to a certain extent. But now with schema, I think because it'll be publicly available data, it just opens up the usefulness to, you know, an exponential degree. And, you know, every time we get an opportunity to implement schema for Any piece of content you put up on a website, you should do it. I see Christine vehemently nodding in agreement, which is always nice.

And I'm sure we'd see Christine nodding if we could see her picture.

Just imagine it's there.

Well, I mean, the cool thing is, is realize some of the people on this call actually developed schema for things that didn't exist a couple years ago. Christine and I When were we talking— when was at PubCon, when did we have Think Tank Night? Was that like 3 years ago?

Yeah, I think so. MGM.

Yeah, so 3 years ago in a hotel room at 2, 3 o'clock in the morning, there's 4 or 5 people, Frank Webtuning from Webmaster World and a lot of people in my hotel room, and we're talking about schema. And what if there was a thing that signified or basically labeled everything the way it should be in terms of object-oriented design and search. Do you remember that conversation, Christine?

I do. Yeah, it was a very good conversation.

So that's kind of where things are today. So it's the natural evolution of what we do.

Yeah. Avner, you had a follow-up question?

Yeah, regarding schema, do you guys— implement in JSON-LD? Also, what kinds of ontologies do you guys recommend? Good Relations, Product Ontology, are there any tips over there?

So Christine, do you want to start?

As Barry was saying in chat, I like the JSON-LD because you can separate it from the page. Which is a nice feature instead of having to intermix it with the HTML. Makes it easier to change and control. I started implementing that last summer and we did see a slight bump when I added it in just for location, logo, and some basic— because it was only supporting some basic concepts at the time. So I think that— I think on ontologies I just add when it's appropriate, whether it's fully supported now or not. I figure sometime in the near future it will be. Mm-hmm. So I have a medical site where they added the medical schema. And I'm sure as that goes forward with Knowledge Graph and other things, that'll be utilized. I do say one thing of hesitation though. Schema, since we do believe— unless someone's going to tell me I'm wrong here because it's changed and I didn't know that— that they do use that data to scrape for things like Knowledge Graph. So you do want to be careful if it's something that you're counting on for visits. I don't know that I would necessarily make sure to schema the heck out of it.

If you look at what happened to PETA during the— I think at some stage we won't really have a choice anymore, will we?

Well, they scrape it all, but just schema makes it easier, right? So I just advise clients, if you have something you're counting on for visits, they still might get it, but you don't necessarily want to make it easier.

Well, the other part is, if you start implementing schema and the rest of your stuff is going to be that much worse in Google Webmaster Tools. If you're worried about errors and that kind of stuff, the more you start adding schema, the more you are visible and crawlable by Google. So the more you get Google's eyes, so you better have the rest of your stuff fixed in Google Webmaster Tools across the board before you implement schema.

Yeah.

Because once you implement schema, all of a sudden now you're getting Webmaster Tools messages you have an increase in soft 404 errors, which you never got until you implemented schema, because you're that more visible to Google. So schema is a powerful tool, a very powerful tool. So use it carefully.

Very good point.

Yeah.

Yeah. So following on from what you were just talking about, Barry, do you consider the role Are the SEOs more adversarial with the search engines or more just trying to play along in their space?

You know me so well, Simon. Again, my real thinking on this is a bit more subtle than what I let out on the blogosphere whenever I go off on a rant against Google. As a general highlight, yes, it is an adversarial relationship, but it's a mutually beneficial one. It's like an evolution where conflicting organisms keep each other sharp and help each other improve to a certain extent. Google both loves and hates the SEO community as a whole because they love us when we implement things like schema and help them understand content better and help them index the web better. They absolutely hate us because we game their algorithms all the time for fun and profit. And vice versa, it's the same with us. Without Google or other search engines, we wouldn't have a job. At the same time, we really hate it whenever they come down with a 10-ton hammer on a scalable tactic. Because that inevitably happens. If a tactic becomes scalable, Google will find a way, either algorithmically or through fear, to discredit and devalue it. So while it's an adversarial relationship, it's also a hugely beneficial one. And I think Google needs us as much as we need them. So yeah, that's the long and short of it, really.

OK. I see Steve nodding and grinning and pointing. So do you want to add something, Steve?

All right. Well, go ahead. Do you want to ask me, or do you want me to just pontificate?

Jump straight in with that one.

Well, I mean, without Google, we don't have jobs.

Yeah.

So let that sink in for a minute. I've been doing SEO for 23 years before Google existed. So Google is kind of pretty much, if we look at my lifetime and my career, '96 Google pops up. I'm working on Yahoo, the web crawler, and then all of a sudden now Google becomes everything and Google forward of everything that we've done. Now, does that mean I'm an algo chaser? Absolutely not. If you do good SEO, then you don't worry about algos ever. If you're a slimy SEO, you algo chase.

Yeah.

That's kind of the way it is. So I think Google is our friend, and I understand, you know, Matt Cutts may look to Barry Adams as he is the minister of propaganda, but I, I'm glad that he's the minister of propaganda. I don't want a bunch of idiots walking into SEO, into my workplace, and screwing up and doing bad things. I hate spam. I hate people that spam websites. I report more— according to Matt Cutts at one PubCon, I report more spam, do more spam reports than any other human on the planet.

See, I have a different perspective on that, obviously, because in the end, I don't get a share of Google's profits. I get paid by my clients. My only loyalty is to my clients. All my end deliverables are there to help make clients successful. And if I have to break random Google guidelines to do that, I will do so as long as I feel the risk is worth the payoff. And of course, the client understands that there's risks involved. I don't owe Google anything, just as Google owes me nothing. You know, my loyalty and my responsibility is only to my clients. So whatever Google pontificates about— bloggers should nofollow their links, or we should all implement X amount of code on our website, whatever. I will only pay attention to that inasmuch as it has a benefit for my clients in the long run. So—

I would agree with— go ahead, Christine.

No, go ahead, Stu.

I would agree with you, Barry, because I've never used nofollow on a client's website and never will unless it's now FTC or SEC in the US required if they're blogging and plugging a product, now they're going to use nofollow. That would be the only reason at this point where I would ever do that. So, you know, Google Webmaster Guidelines, read that. Now, if there's some guy in some place on some Google Hangout telling you Google says this, I'm with you and I'm going to call BS 9 times out of 10 because I know it doesn't work that way. So don't give me this line of crap. Let's go back to Matt Cutts, his minister of propaganda, because he actually said things in a way where you could read between the lines and understand that he was coming from Google's corporate perspective and a liability issue, as opposed to just popping off, which is what we hear a lot of days from some people which will remain nameless.

If you read—

We don't realize how good we had it under Matt Cutts. I mean, you know, I loved to criticize him when he was the mouthpiece. But now that he's not anymore, I just realized how good the man actually was and how useful he actually was compared to the guys we have now. No offense to them. Some of them have their uses in specific contexts, but my goodness, learn how to communicate to the public.

Well, you know, also a lot of the information they give out is wrong at this point, right?

Yes, it's about a 50/50.

The article I wrote last week was, I think Google has a problem in how they've been acting, not with SEOs, but with publishers. In that I'm noticing publishers are caring less and less about getting Google traffic because they've been so aggressive. The communication has been so poor since Matt left. They feel confused. They're not really sure what the benefits are. We explain it to them, of course, and we can make headway. But I'm talking about the average person who's not getting input. If you're someone who lost your website 17 months ago to Penguin— somebody posted on my Facebook the other day— They almost lost their house. They didn't know they were doing something wrong. They lost their business. They lost everything. And now they've had no chance to recoup it, right? So I think that Matt was great not only because Matt knew how the algorithms worked and could communicate really well, but he could also move the needle in certain ways that needed to be moved, and people trusted that. Whereas now with what's going on with Google and lack of communication, and they've even bypassed industry channels to make announcements. and then the aggressiveness of the algorithms, they've kind of set up a potential negative backlash that could be coming their way from not us not caring, but for publishers not caring.

Before we get into Google bashing, we've got 5 minutes left, so let's do some quick-fire ones. We've had some questions coming in. We'll just say that we're frenemies with Google.

So quick questions.

Disclaimer, I'm a Google stockholder. Google is my best friend. That's my retirement. I'm not an enemy or a frenemy. They read what I do. I have clients that have 10,000+ locations in Google My Business, and they make changes based on my requests. I love Google. That's it. Yeah.

Yeah, and I'm just commenting on the environment I think that's existing, not that I'm being hypercritical of Google.

OK. So a question—

I'll happily go on record.

What tools are you guys using for schema?

Structured Data Testing Tool, Chrome Debugger, DevTools, and manual coding, really.

Yeah, that's the same thing.

Christine, you were talking earlier about a site that showed the number of things that were firing off. Did you want to talk about that on a site?

The things that are firing off, I use Google Developer Console and then run a recording, but there's also some other tools. that are really nice. And for the moment right now, I can't think of the name. Someone just showed them to me yesterday. But there are plugins you can use in Chrome where it actually will show you what pixels are being fired, what they're actually tracking in those pixels. And I will see if I can remember in the next few minutes what they're called.

OK. For whoever wants to jump in on this one, image sitemaps, video sitemaps, still worthwhile putting those together, putting those out?

100%.

Oh, yes.

OK. What about unblocking resources? We see people that— that's something that's been popping up a lot. Google obviously wants those resources to be able to get into there and see them. Is that really worthwhile for people to actually unblock those resources?

Yes. I think you risk some form of algorithmic filter if you don't, because it can't actually find out where your content sits on your page. and can't evaluate the importance of different content blocks. So I'd always— Christine?

Oh, sorry. I thought— I'm sorry. I might cut off there, Barry. I didn't mean to interrupt. No, go for it. Yeah. I was just going to agree with him. Google renders the page now, not just crawls it. And if it can't render what's there, you can definitely get an algorithmic evaluation.

Okay. And then one question not for Barry, as he's explicitly stated earlier on in this call. So Steve or Christine, is there any particular focus you would put on technical SEO for Bing rather than Google? No.

Where's the money at? I mean, yeah. I think you're just going to focus on Google because that's where most of your money is going to come from. And while Bing will be a good addition, I don't know that— well, okay, here we go. If you're doing local, then you need to optimize in Bing for people that use Verizon because Verizon uses Bing Maps in their GPS system on their phones. So if you're in the United States and you're doing local stuff for a client that has a lot of retail locations, you must do Bing local optimization for those customers that are on Verizon that are using Bing Maps.

That's a good one.

Great.

And I'm sorry. No, go ahead. I was just saying, I was just half joking, but generally I don't advise clients to optimize for Bing, but optimize Google, and then if there's additions for Bing. That don't hurt them in Google. Because they don't get enough— they just don't get enough traffic from Bing to make it worthwhile to break something in Google.

OK. Fantastic. Well, I think we are actually at the end of our time. We're just hitting the top of the hour now. So I'd absolutely like to thank you guys for everything you've talked about. Wonderful session. So thank you, Barry. Thank you, Christine. Thank you, Steve. And I just want to let you know that the next Sempo Hangout will be in April. It is the Art of Remarketing, and we're still sourcing the speakers for that one. So if there are any— if there is anybody that's interested in chatting about that, please make sure to let Justin know or the Education Committee, and we will see where we go from there. So thank you very much, everybody.

Thank you.