Sign up below to watch future episodes live…
Want to Read Instead? Here is the Transcript.
Jamie: You know what you did.
Dixon: Yes, absolutely. So we got…and it’s really nice to see you guys as well. Joe, why don’t you, for the benefit of the audience, tell everyone who you are and where you come from?
Joe: My name is Joe Hall. I am a technical SEO consultant. I’ve been doing this for way too long. I am from Columbia, South Carolina.
Dixon: And we met 12 years ago, something like that.
Joe: Yeah, something like that. It was in a time when it was much a hazier time for both of us, I think.
Dixon: Yeah. I’d like to say I’ve stopped drinking since then, but you know, there you go.
Joe: Nobody’s perfect. Nobody’s perfect, Dixon.
Dixon: No, I know. I know.
Joe: Except for me. Yeah.
Dixon: Anyways, good to see you again, albeit online. And, Jamie, how are you?
Jamie: Hi, love. I’m doing very well. Yesterday, in Denver, it was 65. It is snowing right now. I am a technical SEO.
Dixon: How did you do that? That’s incredible. That’s just Denver for you, isn’t it?
Jamie: It’s like, if you don’t like the weather, just wait a day. And that’s really where we’re at. There’s actually a lot of the DeepCrawl crew based out of Denver, which is pretty great. I can see my teammates even though we’re all remote. I’m a senior technical SEO with the DeepCrawl group.
Dixon: And I’ve just been told…you told me that you’re coming over to Brighton.
Jamie: Yes, exciting news. Fingers crossed. Ticket isn’t booked yet. But it should be good to go out and see all of you, lovely folks. I haven’t been to an event since a long, long ago, the before times. I’ll be out there.
Dixon: I was going to say, you know, I think I’ve just used my spare free ticket. But DeepCrawl is bound to have loads of tickets, you know, because they’re gonna sponsor everything.
Jamie: Come hang out. Come, be our friends. It’ll be fun.
Dixon: Yeah, absolutely. Good. Well, it would be nice to see you in Brighton, so let’s go. And, Joe, you’re thinking about going to Mexico for DeepSEO.
Joe: I know for certain that I’m speaking at DeepSEO. I don’t know if I will be there.
Joe: It is sort of a hybrid event, I think, but it is in Mexico. The last time I went to Mexico, it’s a really long story, but I’ve had some trouble getting back. And I don’t want to jinx it and do that again. So, yeah, so.
Dixon: We’ve got a few months to try and convince you otherwise then.
Joe: Yeah, exactly, yeah. But I will definitely be speaking there. You know, one way or the other, I’ll be speaking. So, yeah.
Dixon: Excellent. Oh, my friend, Lukasz, is sitting there in the audience as well. So thanks for coming in, Lukasz. I know, in about 30 seconds, you’ll be concentrating on something else, but if you guys want to jump in with any questions or add your 2p, Lukasz, please, do type in the chat, and it’d be great. And of course, this wouldn’t all work without my producer. David, do you want to come in and tell me all the things I should have talked about that I forgot before we start?
David: I just want to mention the fact that many people will be listening to this in Apple Podcast, Spotify, Google Podcast, but if you’re doing that, come and watch us live. Just sign up at theknowledgepanelshow.com. We’ve got another show coming up next month that I will tell you about towards the end of this one. So if you can watch us live, that’s absolutely wonderful. Then you can interact a little bit, and you can ask your own questions.
Dixon: But didn’t we say that about Flash and it’s gone?
Jamie: Well, 98% of the internet wasn’t using Flash. So let’s counterbalance that expectation.
Dixon: Can you give an example?
Jamie: Hear me out. I’m gonna counter that one, because usually, it’s not Angular’s fault, it’s not React’s fault. It is these 75 marketing pixels. Why do you have all of them? The next time a vendor comes to you and says, “It’s magic. Just plug and play this directly above the opening head tag,” tell them, “Not today.” If your tools…measure the ROI of these third-party tools. They impact your performance. If it’s a blocking script, you are dependent on their response time to be performant. Don’t blame the poor Angular.
Jamie: Render blocking resource. Yeah.
Dixon: And I wonder, you know, why can’t you use that with all those scripts, with all those things? Why can’t you just always use the defer tag?
Dixon: Sure. But if it’s a tracking script, you frankly don’t want it…you know, you don’t want it to load at the expense of the user.
Joe: Well, the other thing too, this is interesting that we’re talking about performance, because, you know, there’s been sort of a breakaway in the performance space where there’s been this debate of whether or not…should you be optimizing for, like, the tool sets, or should you be optimizing for the actual user experience, you know? And you can defer scripts like crazy, and you can even delay scripts and preload scripts, and all that stuff, and get these amazing scores, but it really doesn’t…it can screw things up in some ways. So, like, there’s a method that you can basically delay tracking scripts until user interaction. And when you do that, that’s great, but it could screw up your analytics as well, you know. And so I think it’s just one of those situations where you kind of have to balance the two, you know, and it’s a case-by-case basis, you know. It just depends, I guess, is the right way to say it, you know.
Dixon: I love the cat, Jamie. What’s the cat’s name?
Jamie: He decided yet again to crash the webinar. This is Tank. He is very professional. You can see his tiny little bow tie here, ready for business.
Dixon: Yeah. I do apologize to everybody on the podcast, actually. We might have to edit out the Tank cat thing, so, you know. And Giacomo seems to be very happy that we’ve got a cat involved in the whole thing in the audience there. Okay. So, fair enough, I’ll take your point. So defer tag could also screw up your website. That’s a fair point really. Okay. We’ve got a couple…oh, people are joining in here. Hang on. Lots of comments coming in, most of them about nice kitten, but there we go.
Jamie: Can I tell you the good word? Have you heard the good word about history.pushState APIs? This beautiful thing where you can change the address, give each asset its own beautiful, unique location.
Dixon: Just, yeah, okay. So what is that? How do you do that?
Jamie: So pushState is going to go ahead and update the address bar when you’re doing, like, an infinite scroll, which sounds like, you know, you’re in another piece of content, you’ve been going and going and going, and you’re trying to share it out, but it’s not reflecting the content that you’re on now. This is also a problem people see when they’ve got infinite scroll on their sites. There’s a way to go ahead and update very easily and accept it across all browsers, the address that you’re on.
Dixon: So basically, so when do you use this command, this pushState command? I’m not a programmer.
Jamie: Anytime the content changes, update it.
Joe: But it is up to the developer to do that. I mean, they have to implement that, and I think that that’s a really good, I think, workaround the SEO should, I think, push more when working with sites, you know, that that type of push happens, you know. And that is the preferred method with continuous scroll, you know, sites to update. Although, I think it does it work with rel=next and rel=prev on that kind of thing. Yeah.
Jamie: Anytime they’re changing it.
Joe: Yeah. So, yeah, I mean, that kind of thing is great. I think that, from a usability standpoint, I think that’s what you’re mostly talking about, Dixon. I mean, doing what Jamie is saying, I think, is what Devs should be focusing on, you know, and that needs to be implemented more. We need to talk about that more, I guess.
Dixon: If you’re using an infinite scroll then, I guess I’m just trying to understand really as a simple-minded guy, in this regard at least, and I’m scrolling down an infinite scroll. Does that URL start changing in the address bar as you’re scrolling down?
Jamie: Yeah. That’s how, when you’re on a page, you can, like, go, and you come back, and you can stay where you were.
Jamie: So you clicked a link, and then you wanted to go back to the content you were at instead of being shot to the top, and you’ve been scrolling for 10 minutes, and it’s game over. You’re not going back to that. That infinite scroll lets you go back, or the update of the address bar lets you go back to exactly where you were.
Joe: Yeah. As long as that’s implemented, that works really well. And we need to talk more about that. I think that that’s something that SEOs should talk more about is utilizing that as a workaround for, you know, the URL issue that you’re talking about, you know.
Dixon: So when you do do that, do you think Google is quite happy to then index? Because then, potentially then, you’ve got an infinite number of URLs, I guess. Because if you’ve got a scroll, there’s continually changing numbers as you’re scrolling down. If you then got infinite URLs, which could be argued as duplicate content, do you just change one problem for another?
Jamie: Well, it needs to have an index array. It needs to have a known limit. If you have 100 pages worth of content, don’t let it go ahead and start requesting page 200 or resolving with 200.
Dixon: Yeah. Okay.
Joe: Yeah. And then, also, I mean, that’s just an area where you would just use proper canonicalization, you know, depending on what the content is, depending on what we’re working with here. You might just want to use proper use of canonical tags, you know, in that situation, you know. It just depends on what the content is and what you’re trying to do.
Dixon: Yeah. I mean, on InLinks’s site, I mean, because you just got to go to the home page, and if, you know, you put a URL in, you don’t even have to log into the system. You can put a URL in, and what it does is it reads that page and runs our own natural language or an entity extraction algorithm, and it uses Google’s API and compares the entities that Google sees versus the ones that we see. And my URL hasn’t changed. I can’t show all these reports as a marketing guy. I’d like to just, you know, pimp that out and say, “Hey, look, Google can’t pick up these 300 entities on a page, and it just wasn’t built that way.” And we’re too busy building other stuff now to go [crosstalk 00:16:15].
Jamie: It’s a really low-lift change.
Dixon: Yeah, okay.
Jamie: It’s quite low-lift.
Dixon: I’m going to tell Fred this.
Jamie: For the ROI, being able to share these assets you’ve worked so hard to make, if you build them and no one else can access them, do they count?
Dixon: People have misconceptions about the two different… What is the difference? I’m in the crowd that has misconceptions.
And optimizing for them looks very different, depending on what they are, because some of these are client-side render, which means it’s like an IKEA ship. They send you all the parts, your browser builds it up. Some of them, the server builds it when you request it, and they send it back. So that’s their server-side render. Static, they have a copy ready to go. It’s like, when you go to Voodoo Doughnut, which is a great place here in Denver, and you pick out a very bougie, fancy Portland cream donut. You know, there’s one in display, but there’s also a bunch ready to hand over to you. Optimizing for them looks different, because it depends on how they’re built. If everything is client-side, I’m really sorry. That is a nightmare. Every script that is rendered client-side has a probability of breaking, and you have no insight into when or how it broke. Something could be broken for a fair amount of time, and you have no earthly idea.
But at least for myself and I imagine for many other people, when we do tests like that, we don’t do them at scale, right? So just because it worked on one page when I wrote the script on…
Jamie: It works on my machine.
Joe: Yeah, yeah, exactly. It works on my browser. It worked here. You know, it worked here where, you know, it works this one time that Google indexed the page. But the problem I have, the problem I see a lot of is these pages that have, like, you know, 10,000, 20,000 URLs that are utilizing a client-side render on each page. And if it’s something like, you know, they’re client-side rendering a batch of internal links on every page, well, okay. If just one of those pages has an error during the crawl or maybe even a batch of those pages have an error during the crawl, it can significantly cut down the internal crawl and the internal link equity spread for that crawl. And like Jamie said, if you don’t know how long it’s been like that, then you could significantly be cutting down internal link equity spread as a result of that.
And so it’s one of those situations where I really don’t like client-side rendering for that reason, because I’m worried that there’s all these opportunities for it to break on the search engine side, and it’s gonna significantly hurt you if it does break. And that’s why I’m just kind of always really uneasy about it, even when I see things, like, that work well, because, like, you know, Angular and React, they both have kind of good ways to get around all that. Like, they’ve got different things you can do to implement server-side rendering and whatnot. But it’s still that opportunity for failure can still occur, you know. And so I think that we need to talk about, like, as a community, when we talk about these things, we should say, “Okay, look, like, you can do this, but should you?” you know. And you can implement these tools and whatnot, but here are the risks in doing that, you know, not just saying, “Yes, well, it works, so do it,” you know. I think that’s kind of dangerous for some sites, you know.
Jamie: Well, here’s the thing, yeah, you can, but it’s a probability of failing. Every single one of them is a probability. So a lab test has a set boundary of where it’s running from, how it’s running, what it’s emulating. In the real world, somebody with shoddy cell phone reception walking behind a really blocking building could change how that page loads. And it’s worth noting that there’s four causes of poor LCP. One of them is client-side rendering. This is significant. You are asking that browser to go ahead and assemble everything many times. These users are on mobile. If they’re outside the U.S., data is expensive. And we are shipping so many things that they don’t need. You know, I gave the analogy of, like, client-side rendering is like going and getting a flat-pack bookshelf from IKEA. Well, half the time they ordered a bookshelf, we also sent them half a table set as well. They didn’t need it, it doesn’t function, it has no purpose, but we sent it, and they had to assemble it.
Dixon: I love that analogy.
Jamie: They can be, but here’s the thing, anytime you’re relying on a third-party as code, you also have a security risk, your performance risk. The most performant and secure assets are those you don’t ship. So we tend to do kitchen sink tags on our sites. We keep adding scripts, and adding things, and adding features, and adding functionalities, until it is so absolutely bloated that we are just a dragon with a bunch of Allen wrench keys going, “This is fine.” It’s not how the experience we want to give our users. We can’t just ship all of this off without being considerate of how we’re using their bandwidth. There are options out there where we could do things that split the difference, something like progressive hydration that would let us ship the hero content, which the user is coming for, critical things like meta tags, all of the good bits. And then that secondary, that tertiary content, that can be loaded in the client’s browser. That footer, no one cares about your footer. Like, load that client-side. That’s fine.
Jamie: But it comes to another execution. I’ve been a CRO, and I’ve seen, when you use a global tag, when you block that entire page while you’re waiting for your third party A/B testing platform tool, you are crashing your conversion rate, rather [crosstalk 00:27:08].
Joe: Yeah, sure. That’s a good point.
Jamie: I have that.
Joe: That’s a good point, yeah.
Jamie: So only block what you need. Make that element.
Jamie: Please stop, yeah.
Joe: …that does everything. You know, break those out, but don’t break them out into 10 files. If all 10 files have to load, then you may as well just have one code to the computer, But the problem with that logic is that, you know, some pages need certain functionality and other pages don’t need that functionality, and it’s very difficult for us…well, I say us, for you guys, as the developers, to know in advance which pages, which of them is gonna be needed.
Jamie: There’s tools for that. There’s no way a human can go through and map that out, but there are tools for tree shaking and for code splitting. You can call a webpack in your pipeline, and it goes, “Okay, this page uses this code. I’m gonna ship that.”
Dixon: So how would you go about optimizing that, you know, what script to call, Jamie?
Jamie: I would automate it using a library, like webpack, so it can go ahead and do the code splitting and tree shaking for me. Alternatively, if that’s not an option, let’s look at what’s in that global bin, what are we shipping in every page, and go, “Hmm, some of these only fire on specific templates.” So then we begin to enter that conditional logic Joe mentioned where, you know, if the template is the video player, then we load the script. Look in that global junk drawer.
Dixon: So webpack, I remember Martin Splitt also mentioning webpack, so, you know, that was a good sign. So can you explain webpack a little bit because it sounds like a resource that probably, you know, we should know about?
Dixon: So if I’m a simpleton with a WordPress website…well, sorry, not simpleton. I am a WordPress man so I use my WordPress websites, and I’m sure that I’ve got loads and loads of plugins that are absolutely…well, hopefully, not too many. And I have had people telling me [crosstalk 00:33:09].
Jamie: That’s your junk drawer. It’s time for us to go through and clean that junk drawer.
Dixon: Is there a webpack for SEO, for WordPress? I don’t know. Is there a webpack plugin for WordPress?
Joe: I don’t know. Jamie, is there that you know?
Dixon: Looking it up where we’re going.
Joe: Yeah, I think that’s one thing about WordPress, it’s really easy to make mistakes, because there is so much out there, so much available. I will say, like, I don’t think that if you have a website, you know, a WordPress website that you care about, I would not add plugins without help if you don’t know what you’re doing. And you really need to understand what that plugin is doing and how that plugin works and what the major kind of features are for it. And also, you should only add plugins that are regularly maintained and regularly updated.
Dixon: And I think that’s pretty much, you know, you can have a look at the community behind that plugin really easily before you start.
Joe: Yeah, you can, yeah.
Joe: You absolutely can, yeah.
Jamie: I mean, I could go ahead and release a plugin right now that, like, makes your page faster, and it just puts flame decals on it.
Jamie: There’s not a lot of…
Dixon: Remove the code. Just remove the code, nice white page there.
Jamie: Oh, there’s a great library that’s called thanos.js, and it just snaps half the code off the page. I think it’s the best thing ever. Automatically makes you save more performance, 50% lighter.
Dixon: You’re only allowed to program in 20 lines of code. The whole page will go in 20 lines. That sounds like a good way to force people to optimize.
Joe: That’s true.
Dixon: Okay. So let’s talk a little bit about DOMs and View Source versus Inspect and the differences for people, because another naive thing that I said before I came on is I never use View Source anymore, and you both kind of looked at me and said, “Why wouldn’t you use View Source?” Because I’m always using the Inspect and assuming that I don’t want to use View Source, because I want to see what the rendered code is. Why is View Source in the Chrome as an option when they’ve got Inspect, and what’s the difference anyway for everybody else?
Jamie: It’s part of the pixel pipeline, my friend. If you have a noindex tag in that View Source, it’s never going to get rendered to see the index. So it’s an order of operations. We think of google as this giant monolith. It’s code. Code runs in an order. It starts with viewing the HTTP responses, and it moves through the source. Then, it grabs all the resources and renders.
Dixon: That it didn’t need any of it.
Joe: Yeah, I think so.
Jamie: Oh, absolutely.
So I think what I use View Source for a lot is comparing the two and understanding, “Okay, if there’s something showing up in the rendered version in Chrome tools, and it’s not showing up in the View Source, that means that it’s client-side rendered.” And if that is something that, you know, helps with SEO or as a part of the SEO process, then that should be understood, you know. And it doesn’t mean that the engines are not seeing it. It just means that they’re having to go through an extra layer of work to see it, you know. And so I think that that’s why I use the View Source and the Chrome DevTools, Inspect tools, and stuff like that, to make a difference between the two, you know.
Dixon: Jamie, do you want to jump in on anything of that, or?
When we see that full DOM, we could do something like comparing the output from URL inspector to that which we have in the live page, which you can copy and paste out of URL inspector. They added a fine functionality into the rendered HTML there, and I love it. You can compare that to what you have in your user’s page and see where the gaps are. It’s very useful. It’s important to note, though, when you do a live test, live test bypasses Google’s extremely aggressive cache. They are ignoring your max-age tag because no one used it right, and this is what happens.
Dixon: Okay. So I love your alliteration as you walked through that, but I didn’t get…what’s a specter? What’s my specter?
Jamie: Specter? Inspector.
Dixon: You said specter. Oh, inspector, okay.
Jamie: Inspector. URL inspector.
Dixon: Sorry, okay, okay, sorry. Inspector. Inspector.
Jamie: Yes. I’m now going to call URL inspector Specter. It’s the ghost of a URL’s past.
Dixon: I thought it was something out of James Bond coming through here, yeah. So [crosstalk 00:42:45].
Jamie: Hello, Blofeld.
Joe: Yeah. Yeah. And another thing about the edge SEO that I’ve heard from most SEOs that utilize it is that it makes the SEO process much more manageable for, especially, when you’re working with a company that has a big team, and it’s hard…
Dixon: Sure, it does, However, if you’re the SEO and you go in control of Cloudflare… Rob Watts’ comment. I’ll ask that question in a second. But if you’re in control of Cloudflare, you could really screw up the developers because developers can’t work out why the hell that thing isn’t working.
Joe: Yeah, yeah, definitely. I mean, like, but it has to be sort of, like, this agreement, you know. I mean, if that team can’t get to your tickets for another six months, then they have to agree to giving you some…
Dixon: Give you a workaround, yeah.
Joe: Yeah, give you a workaround. And I mean, that’s just kind of, like, a simple kind of compromise you make with the Dev team and say, “Look, like, if you can’t give us this in six months, then at least let’s do this instead, and we’ll work with you to keep you informed of everything that we’re doing,” and kind of co-exist in that regard. But, yeah, it is a lot easier for a lot of SEOs that manage enterprise accounts and whatnot to have that level of access, you know.
Dixon: Okay. David, can you bring up that question from Joe…that comment from Rob Watts, and I’ll just read it out for the podcast.
Jamie: That’s a great one. Thanks, Rob.
Dixon: Rob Watts says, “Cloudflare I found, removed html comments which I used to test a little thing once. Took me ages to figure it all out! So, yes, you have to be careful for sure!” That’s kind of interesting.
Jamie: They’re doing modification. They’re cleaning it up so it’s a smaller file. They’re removing unneeded spaces, comments.
Dixon: Yeah, you don’t need comments when you have a code, do you? You know.
Dixon: Like, this comment that says, “Please don’t read this.”
Jamie: Stop logging things in the client’s console.
Dixon: I remember, at PubCon, Brett Tabke used to use comments in the robots.txt file to advertise for job roles. So you know, once you’d started looking at his robots.txt, that’s when you can start applying for jobs at PubCon, so.
Jamie: It’s visibility and awareness into your site’s PEMDAS, if you will.
Dixon: I like that. I mean, I think that pipe thinking order, Jamie, has been my…I mean, it’s pretty obvious when you think about it that, you know, of course, you know, what happens at the DNS level is much more important, ultimately, than what happens at the server level, which is much more important than what happens at the…but they can all wreck your website. It doesn’t really matter, so.
Jamie: I mean, I found a job posting in a header the other day. I thought that was very clever. It was like, “Hi, you found us. Come apply for us.”
David: Sure. Next month, it’s not on the usual Monday. It’s actually on a Wednesday, and that’s because Monday, the 18th, is Easter Monday. So instead, we’re going to be doing it two days after that, on Wednesday, the 20th of April. And that particular subject is going to be technical SEO quick wins. We’ve got a couple of guests booked for that one already we’ve got Wilhemina Gilbertson-Davis from BAT, and we’ve got Cara McClure from Mindshare. So sign up to watch that one live over at theknowledgepanelshow.com.
Dixon: Okay, brilliant.
Joe: All right, cool.
Dixon: And thanks to InLinks for sponsoring this stuff, as always. I’m the CEO of InLinks, so they’re always going to have to sponsor this thing.
Jamie: Thank you for sponsoring you. We appreciate all of your efforts.
Dixon: That’s what you got to say really. Yeah, absolutely. So, guys, just before you go, if people wanted to find you, because clearly, I’ve got two very, very bright people on the panel, where do the people…Joe, how do they go and find you?
Joe: You can find me on Twitter, @joehall. I talk about SEO and hot dogs.
Dixon: And that’s Joe with an E for those who are on podcast.
Joe: Joe with an E H-A-L-L on twitter. And then on LinkedIn. Don’t find me on Facebook. I hate Facebook. I’m there, but I’m not pleasant there. So don’t find me there.
Jamie: I don’t think anybody is pleasant there.
Joe: Yeah. Sure, yeah.
Dixon: I try. I try to be pleasant there. I’m old. I like Facebook.
Joe: I don’t try. I don’t try.
Jamie: I like Twitter because it makes you fall in love with a stranger in 280 characters. Meanwhile, Facebook makes you hate your family, so.
Joe: Yeah, exactly. Exactly, yeah. Yeah.
Dixon: Yeah. Echo chamber is not good on Twitter. It’s true.
Dixon: Jamie, how about you? Where do people find you?
Jamie: I am on Twitter, @Jammer_Volts, or you can just look for the blue hair. It’s pretty easy to spot me.
Dixon: So, okay. So it’s Jammer, J-A-M-M-E-R…
Jamie: If you’re at Brighton, come, say hi.
Dixon: …underscore Volts, as in electrocute yourself.
Dixon: So, yeah, that’s brilliant. Guys, thank you ever so much for coming on. Really appreciate it. It’s been good. I know we were trying to get Nick on as well, Nick Ranger, but we’ll get her on another show. So we’ll get that sorted. And, guys, thanks very much. And for everyone that’s watching and listening, please come back again soon. Cheers. Bye, guys.
Joe: Bye-bye. Thanks. Bye.
Leave a ReplyWant to join the discussion?
Feel free to contribute!