Give me magic” to “, hey here’s, my user story,.” “. I would like to accomplish three pieces for acceptance criteria..”, You can bridge the gap, Hello and welcome to another episode of SEO. Myth busting With me today is Jamie Alberico Jamie. What do you do in your job? Thank you so much for having me here. I’M a technical SEO with Arrow Electronics. That means that I am embedded with a number of dev teams across a number of projects, And we tried to execute these initiatives, get new features available on the site in an effective and search friendly way, And that means a lot of times.
It’S a list type language They’re, like a lot of misconceptions, coming from both worlds together and clashing here. I don’t think it is the devil. I think it has its benefits. I mean it allows us to build really cool and fantastic stuff on the web and be really responsive to what the user does and wants to do with our applications. And it has moved the web from becoming or being a document platform towards an application platform.
One thing, for instance, is you probably have built single page applications right? Oh, yes, Has there been problems in terms of SEO when they rolled out, I I was pretty lucky. I had a dev team who believed in SEO. That’S good, That’s really good. That was actually my the big moment of my career when I got on the technical SEO And I came and I talked to you one of my new developers for the first time with this very specific problem I was trying to solve and he just paused and Looked up from his keyboard and went “ you’re, not snake oil”, So I think we’re making a lot of progress between SEO and devs.
That is fantastic. It’S a great story, So you might hear a few people in in the community going like ooh. Should we do a single page application? Is that risky And one of the things that a bunch of developers are not aware of, and some SEOs are not necessarily communicating all the time is that we are stateless. So that means with a single page application. You have a bit of an application state right, You know which page you are looking at and you how you transition between these pages.
I click on the main navigation for this particular page and then I click on this product and then I see and everything works, But that might not do the trick because… You need that unique URL. It has to be something we can get right to Not using a hashed URL and also the server needs to be able to serve that right away. If I, if I do this journey and then basically take this URL and copy and paste it into an incognito browser Mm-hmm, I want people to see the content, Not the home page and not a 404 page.
I mean Everyone’s using it, but no one’s talking about it that much It was just like yeah. You just load data in as you go and that’s perfectly fine. We are able to do that. Also, I often get us about how that affects the crawl budget.., Let’s talk So what worries you about that? Well, if we’re using Ajax and me requests, say a product detail page and we’re using Ajax to supplement a lot of pieces of content to it.
Right, Googlebot’s requested one URL and it’s gotten back nine Yeah, because each of those Ajax calls had a unique string right. How do we handle that and does that negatively impact our crawl budget? So I wouldn’t say it negatively impacts your crawl budget, because crawl budget is much more complex than you might see this It’s one of these things that looks like super simple, but there’s more than meets the eye, We’re doing a bunch of caching right, because we expect That content doesn’t necessarily like update too much.
So if we were to version our Ajax calls, yes, those could be cached as those could be cached exactly. Yes and then that’s that’s one way of working around it. If you can do that, if that’s a possibility, The other thing is, you could also consider it not just an issue for The crawl budget, but also an issue for the user right, because, if you’re on a slow network or spotty network connection, It might flake out In the middle – and you were your left foot broken content, That’s not a great user experience.
You want to probably think about, like pre-rendering or hybrid, rendering or server side, rendering Anything in between there And crawl budget is tricky generally, because we are trying to deal with the whole “ host load” situation. So what can your server actually deal with? So we are constantly adjusting that anyway, So it’s like “, oh this affected our crawl budget negatively.”, Not really because we just like had host load issues with your server, So we like adjusted it anyway, so we had balancing issues across your entire content.
We know. Since Google I/O there is actually a gap between our initial parse and our HTML rendering. But I want to know more because Googlebot follows HTML. / HTML5 protocols – Yes, There’s some nuances there. I don’t think I know I didn’t know about Where say: you’ve got an iframe in your head and you’ve got a closing head script right there That ends your head for Googlebot Yeah. All of our lovely meta content, our hreflangs and canonical’s below that have a tendency to exist.
So this is definitely the start of it And as we get the HTML in parallel to extracting the links and then crawling these, we queue them for rendering. So we can’t index before we have rendered it, because a bunch of content needs to be to be rendered. First, In a way that better fits us, if we’ve got a single page application, We now.. Googlebot has the template. They just got to grab the content that fits within there Yeah.
That doesn’t mean that you should always give us a page with a bazillion images right away, because that’s just not going to be good for the users, Because they’re going to have to then…. If you’re on a really old phone. And I have a pretty old phone and you have a pages full of images and transitions and stuff, then you’re like.. “. I can’t use this website.”. So pre-rendering is not always a great idea.
It should be always a mix between Getting as much crucial content and as possible, but then figuring out which content you can load lazily in the end of it. So for SEOs. That would be. You know we. We know that different queries are different. Intents Informational, transactional,…, so elements critical to that intent should really be in that initial rush Exactly and you might consider if, if the intents are wildly different And the content is very, very different, consider making it into multiple pages or at least multiple views if you’re Using a single page Application so that you have an entry point for the crawler to specifically point at it when when it comes to surfacing The search results, So treat it like a hub and let the users branch out from there.
Yes, so that’s where we’d use! Maybe our CSS toggle for visibility. That is a possibility just having different URLs, is always an option, especially with the history API. You can probably in the single page application figure out which route to display and then like have the content separated between different routes or Be a little more dynamic. There.. We support parameters, So even if you use URL parameters.
. Basically expose the state that is relevant to the user in the URL. What other ways does that benefit our users, because our ultimate goal is to make them happy And that’s our ultimate goal too. So like we are, we are the same in terms of what our goal is. We both want to surface useful information to the user as quickly as possible, So The users benefits are especially if you do like hybrid rendering or the server-side, rendering that They get the content really quick.
Normally, if it’s done well, if it’s not overloading their device And they get to jump in right where the meaty bits are right. So if I’m looking for some specific thing – and you give me a URL that I can use to go to that specific thing – I’m right there and I’ll have a great time, because it’s the content that I needed So yeah. If you have performance metrics going up as well, then, even if I’m on a slow phone and a really spotty network, I still get there.
I mean our performance metrics, that’s based on a lot of pieces. We have a stack of technology. That is true. What should SEOs look for in our stack? Where should we try to identify those areas where we could have a better experience for not just Googlebot, but our humans Yeah? So I think a bit that is oftentimes overlooked, not by a SEOs But by businesses and developers, is the content part. So you want to make sure that the content is what the users need and want, and it’s written in a way that helps them.
But on the technology side,… Wait So that blurb at the top people always do where the like. Here’S my hero image and then 500 words about this thing And I’m a human who wants to buy something and there’s so much stuff in the way…. Yeah. Don’T do it At least like have two pages have like the promotional page that you want to do direct marketing towards and then, if I specifically look for your product, just give me your product.
Just let me let me give you money, So I think Talking about performance and all the different metrics, it’s a bit of a blend of all the things like Look at. When does my my content actually arrive, when does my page become responsive? So you look at First content for pain. You look at time to first buy as well less important than the first content full paint. I would say, because it’s fine, if it takes a little longer.
I highly recommend testing testing testing testing. What testing tools would you recommend? So I definitely recommend lighthouse. That’S a great way. Web hint is more More broad approach as well, and you could also use PageSpeed insights or the new SEO audits in lighthouse. Mobile-Friendly test also gives you a bunch of information. Pagespeed insights is look at that full page though Mm-hmm and we had a bit of a bit of a gap.
We have almost this futurist Lighthouse, where we want that time to interactive, and then we have people adopt this methodology. That’S how we got you know so much contact via Ajax, because full page load is fast, but all that content was still coming…. I would recommend lighthouse that gives you like the Filmstrip view of when things are actually ready for the user to work with. So I would highly recommend looking at lighthouse but PageSpeed insight Gives you a good like first first view over and it integrates with lighthouse really nicely now.
Thank you very much and I hope you enjoyed it and see you next time. Have you ever wondered where, on the map, you should put UX and performance when you’re talking about SEO, So have I Let’s find out in the next SEO? Myth-Busting episode,
You have to try the best pumpkin seed snack from Spunks! Learn about the creators by watching the video below.