Keira Davidson (00:22):
Hello and welcome to the Tech SEO Podcast. I’m Keira Davidson, your host, and today I’m joined by Sara. It’s great you joining the podcast today. I can’t wait to speak with you. Let’s kick things off by finding a bit more about you.
Sara Moccand-Sayegh (00:37):
Hi, so thank you for having me. So about myself. I work at Leap, a web and Mumbai development agency. I co-hosted a [inaudible 00:00:50] called SEO North Switzerland, and I’m also part of the Community Women in Tech SEO. And I just feel that is one of the more inspiring community that exists in the tech world.
Keira Davidson (01:06):
Couldn’t agree more with you. The Woman in Tech SEO Community has been really useful for me personally. Like yourself, I came across you in there. And so many of the people have been really helpful and lovely to work alongside with.
Sara Moccand-Sayegh (01:22):
Yeah, for me, it’s the same. I mean, I met some fantastic people in that community.
Keira Davidson (01:28):
So today the plan is to talk around JavaScript myths for SEO. And as an SEO, as soon as I used to think of a JavaScript, it’d be like, oh my God, red light. Geez, this could be bad, sort of thing.
Whereas JavaScript can be okay. But we’ve got to set these myths straight to make sure people are aware of this transparency around it all. So that brings us onto what is your first myth that you found relating to JavaScript?
Sara Moccand-Sayegh (02:09):
So my first myth is that Google can index JavaScript without any problem. Okay. Before I dive deeper into this myth, please let me explain something. So, as I said at the beginning, I work in a development company. So for me, this myth come from the developers because for SEOs, we are always scared about JavaScript, as you said. And developers are not scared enough about JavaScript.
So I would say that is the main problem. And we need to find a common ground on that. And that is the reason why I wrote down this first myth because of the feedback then I had inside the development company.
Keira Davidson (03:00):
Yes.
Sara Moccand-Sayegh (03:00):
So probably, I mean, most of your auditors know how Google process JavaScript, but let me give a refresh. So then it makes it clear for everybody. So how Google plus JavaScript, normally it will happen in three phases. You will have the crawling, then you will have the rendering, and you will have the indexing phases.
So when we have a website that doesn’t have Java script. So let’s say a plain HTML website. And then what will happen is that you will have a URL for example, and then the HTML will be downloaded. Then you will check this HTML, you will find links. There will be the extraction of the links. Okay?
Keira Davidson (04:02):
Yep.
Sara Moccand-Sayegh (04:03):
And then you will have a download of the CSS file and everything will be sent to caffeine for indexing. So that’s mean that you will just have two phases, crawling and indexing, and that’s all. And that’s make it so much easier. With JavaScript, especially with a website then our heavy JavaScript website. We will speak a little bit more about that in the next few minutes, maybe.
So the situation will be a little bit different. If you ever seen a website having JavaScript and you remove, you can have all this extension where you can remove JavaScript for example.
Keira Davidson (04:03):
Yes.
Sara Moccand-Sayegh (04:50):
And then you will see, then the page is completely empty. There is nothing. And why that happened because the HTML of the page is empty too. There is nothing on the HTML. So that’s mean then if links are so important and then Google try to, it will download the HTML, and then it will look for the links. But I have no links because there is nothing on that page. Okay?
Keira Davidson (05:20):
Yes.
Sara Moccand-Sayegh (05:21):
And then we are obliged to create, by we I mean Google, obviously. It’s obliged to create an extra step and that extra step is the rendering.
Keira Davidson (05:34):
Yeah.
Sara Moccand-Sayegh (05:34):
Okay. Because it needs to see the initial HTML and the final HTML in the almost, it is not exactly the same, but almost in the way that we see it. Okay?
Keira Davidson (05:47):
Yes.
Sara Moccand-Sayegh (05:47):
Because like this, it can find the links and can extract them. It can do exactly the same process in a certain sense, then it would be with the crawling and indexing. But you could see in the rendering, it will find the link. It will find the entire, the content of the page too. Okay?
Keira Davidson (06:14):
Yes.
Sara Moccand-Sayegh (06:14):
So that is why this rendering phase is important because it give you, it will give to Google a better vision. Okay. I would speak about Google just because it is the main search engine, and the one then would probably render JavaScript best. So the more advance on that.
Keira Davidson (06:38):
Mm-hmm.
Sara Moccand-Sayegh (06:40):
Okay.
Keira Davidson (06:42):
And that makes sense, because I personally have come across websites, where if you turn off JavaScript and then keep critical areas of the sites such as the navigation, they don’t work. And that causes a massive issue because search engine bots then can’t discover all these links within the nav to then find all these pages, which need indexing. It just cause a massive headache.
So yes, it’s great using JavaScript, but we’ve also got to do some testing to ensure that the page is able to be rendered and indexed because that is critical for us as SEOs.
Sara Moccand-Sayegh (07:19):
Exactly, exactly. So I will already switch a bit here and there, as you are speaking about that. Yes. So as SEO, you’re absolutely right, we need to check and we have some tools that support us. Like the search consult or many other tools.
We can at least see a little bit how it’s rendering and is Google taking everything? We can see if there is a problem in the JavaScript part. So you are absolutely right. That is part of our job and we need to check that.
Keira Davidson (07:56):
Mm-hmm.
Sara Moccand-Sayegh (07:57):
So coming back again to the rendering part. So as we say, and as we say now about the tools and what you were saying, then we need to check. So the rendering is dedicated. It’s very dedicated. So many things can go wrong in the rendering part. So more resource you are having, more complicated will be the rendering part because there is all the fetching.
So it’s a little bit complicated. So better if you reduce as much as possible, all this part. Then there is another problem with the rendering. It depends obviously on the size of your website, but rendering require a lot of resource.
Keira Davidson (08:45):
Yes.
Sara Moccand-Sayegh (08:46):
And we know the resource are limited. So we will speak a little bit about that later on.
Keira Davidson (08:55):
That makes sense. Yeah. That sounds really good. And I think it highlights the importance to see how your page is rendering. Like you said, it can be done in search console. It can be done in dev tools. You can see the little square blocks sort of how search engines look at it, which is, I find quite fascinating, especially when it’s loading, when you’ve got like random blocking issues. And it’s like, oh, just blank screens initially. And then the page is loaded.
Sara Moccand-Sayegh (09:22):
Oh yeah. That give you an indicator at that point when you’re waiting. And you’re like, oh my God, there is nothing. Why there is nothing? Oh, okay.
Keira Davidson (09:32):
Exactly.
Sara Moccand-Sayegh (09:33):
So, yes, I understand what you mean. So this myth a little bit come from developers, then there is no problems. And then the question is what can we do? Because there is something that I have learned from developer. We need to give them a little bit of guidance.
Keira Davidson (09:33):
Yes.
Sara Moccand-Sayegh (09:55):
Okay. As much. I mean, I have learned so much from the developer. Because each time then I have a technical question, then I absolutely understand nothing. I will go and say, “I have a question.” I give them a bad headache because I will continuously try to understand. So, okay. But anyway, they’re fantastic. They help me, but we still need to give them a little bit of guidance too.
Keira Davidson (10:20):
Mm-hmm.
Sara Moccand-Sayegh (10:20):
And these are some of … We can have some solution to help the web rendering service. So for example, if the initial HTML and the final HTML are the same, or similar, that will help for sure the web rendering service.
So for example, if you use server side rendering, that will help. We will explain. We will discuss with you a little bit about it later on, but that’s something that could help. Then we often check in the dev tool, for example, if some, all the JavaScript use it? Yes or no? So for example, a developer could use three shaking. So it’s a technique to remove code then is use it, or like dead code.
Keira Davidson (11:17):
Yeah.
Sara Moccand-Sayegh (11:20):
So, I mean, I don’t know exactly, as you would say, but whatever it is that you don’t need.
Keira Davidson (11:20):
Exactly.
Sara Moccand-Sayegh (11:26):
That is an option. And then most of developers nor they will use like Webpack. And I test it myself in the past and I really hope that I would never, ever again, could use Webpack for the rest of my life. But what I’ve learned from that is that Webpack create bundles. And so these bundles are fantastic because bundles of code all together. But sometimes they’re too big.
Keira Davidson (11:26):
Which causes a problem then.
Sara Moccand-Sayegh (12:05):
Yeah. And then became a problem. Then something that is good, it became the problem. So there was, I remember a couple of years ago I’ve seen, I don’t remember her name, but it was the head of SEO of Philip Morris International. And she said, “Bundle your code, but split into reasonable bundle.” And I was like, oh my God is so much that.
Keira Davidson (12:29):
That makes perfect sense.
Sara Moccand-Sayegh (12:33):
Yeah. That is like the perfect sentence. And yes. So that’s something, the sentence I take it from her. Sadly, I don’t remember her name, but yes. That are some idea on how you could help also developers. I would give direction.
For sure there are many more. Now I don’t know how is your experience with developers? But obviously they are aware of many things at the moment and you make them aware. They will try to find solution and search. I don’t know-
Keira Davidson (13:07):
Exactly.
Sara Moccand-Sayegh (13:07):
What do you see?
Keira Davidson (13:09):
And I think if we can make the developer’s job any bit easier, then it’s definitely within our interest to do so. As it should hopefully result in fixes being implemented a bit quicker.
Sara Moccand-Sayegh (13:22):
Exactly. I absolutely agree with you. And then there is a last part. That is a little bit complicate to explain, but let’s try to do it together. So there, I will ask a little bit of support. Because we know then we have the web rendering service.
Then you have, so what you want to do often, to have a better user experience, it will be having a cache. So you will cache in the other. Which means that sometimes there is the risk, then Google will not know that you refresh your JavaScript file. Okay?
Keira Davidson (14:09):
Yes.
Sara Moccand-Sayegh (14:09):
So let me give an example because I think then it will be much easier to understand with an example. So often, I don’t know, tell me your experience. But what I’ve realized is that normally eCommerce website, they have a lot of products and then their products will be populated with JavaScript.
Okay. So now let’s side on this product, you have some new stuff. I don’t know, which new stuff, but some new stuff. And then what you will do is developer will create a new code, but they will add it on the same JavaScript file. And then you will have this new code with the same name as before, and then what? Nothing, because Google, as we say, will have limited resources.
So Google will not re-crawl the new file. And would just keep the old version because you have exactly the same name. So why should it crawl the website? So what happened is, and that is what Google advise to use. And that is something that you can discuss with your developers, because for sure they know what I’m speaking about, is to use content fingerprint. So you have on your file, you will probably, you will change all the numbers that came after the-
Keira Davidson (14:09):
File.
Sara Moccand-Sayegh (15:46):
The file. Yeah. You will change the number and then it will be point GS. Okay?
Keira Davidson (15:46):
Yes.
Sara Moccand-Sayegh (15:54):
A and okay. That you can also find it in the dev tool. I will not explain it because maybe it’s a little bit complicated in a podcast, but you can also find it in the dev tool. And you can check if your company is using content fingerprint. For example, in my company, we use query parameters.
Keira Davidson (16:16):
Yes.
Sara Moccand-Sayegh (16:17):
Instead of content fingerprint. It’s not the most indicated, but it looks and it works fine.
Keira Davidson (16:24):
I guess it does the same thing as well, doesn’t it? It’s a way of identifying each file and making that file unique so that when a new, updated version is created, it can be assigned a new parameter.
Sara Moccand-Sayegh (16:40):
Exactly, exactly. You got it perfectly. So yes, it’s exactly that. So that is something that you can always do also to help a little bit the process. But again, probably discussing with developer, you will have tons of other fantastic idea and way then you can improve your JavaScript and help the web rendering service.
Keira Davidson (17:04):
Wow. That’s yeah. I definitely think that’s a good idea. Also, this popped into my mind, do you know, let’s say a JavaScript file has been updated on a particular product page. If the SEOs submitted that page in Google search console for indexing, would that then mean, because obviously that would then start a crawl for the page. Would that then help search engines identify that their file has been updated and a new name has been given to that file? So they recognize it?
Sara Moccand-Sayegh (17:42):
So if you gave the new name, yes. If you keep the old one, I don’t think then that will make, maybe will make the difference. But if you keep the old file name, I’m not sure then-
Keira Davidson (17:42):
Okay.
Sara Moccand-Sayegh (17:54):
That will help. I mean, because anyway, Google cache is not the same thing, same type of caching, but it will cache already the resources. So it will have already all the list of resources then you already gave him. So I don’t know exactly how it will work in that case. Because you are submitting and say, “Hey, do it again all.”
Or if you’ll keep anyway we not do it again all, because a lot of resources are already cached and you see, okay, this is equal to that one. So why should I do it? So-
Keira Davidson (18:32):
Exactly.
Sara Moccand-Sayegh (18:33):
I would advise anyway to change the name. But that is a good question and we can always ask Google.
Keira Davidson (18:40):
Yeah. Let’s just stick with changing the name, just to prevent any kind of issues.
Sara Moccand-Sayegh (18:45):
Exactly. So you changed the name, or you do as I do time to time, then I’m like, okay let’s ask the Women in Tech Community. Let’s ask directly to Google. So I will be it like, sorry, I have a question. Yeah, that is an option. But yes, I would say intuitively, I would say you need to change it to play it safe. And that’s probably the best solution, but yeah.
Keira Davidson (19:15):
That sounds great.
Sara Moccand-Sayegh (19:15):
I’m not 100% sure.
Keira Davidson (19:19):
No, that’s fine. So another myth that you might have faced is Google has no problem with SPAs.
Sara Moccand-Sayegh (19:31):
Yeah.
Keira Davidson (19:32):
Can you quickly explain what an SPA is just for my benefit?
Sara Moccand-Sayegh (19:35):
Yeah, sure. So a single page app. So that come from the previous myth. Because if you have no problem with JavaScript, why should you have a problem with a single page app? So let’s check together a little bit more of what is a single page app before diving a little bit deeper.
So a popular single page application framework are like Angular, Reactive, UGS. I’m sure then you know many more than I do. So there are tons of this single page application framework. So how a single page app works? So let’s start by making a difference and probably is the easiest way to understand how they work. So the traditional website is a static website. Okay?
Keira Davidson (20:27):
Yeah.
Sara Moccand-Sayegh (20:27):
Which have for each page you will have a HTML page and then you will have a CSS and the JavaScript resource, this one for each page. Okay?
Keira Davidson (20:40):
Yep.
Sara Moccand-Sayegh (20:40):
Now when you have a single page app, what you will have is just a single HTML page for all the … They’re not really pages, but let’s speak about pages. It would be a little bit easier. For all the pages then you can imagine, there is just one single HTML. Okay?
Keira Davidson (20:58):
Yes.
Sara Moccand-Sayegh (20:59):
The problem is then this was single HTML has no content.
Keira Davidson (21:04):
Okay.
Sara Moccand-Sayegh (21:05):
So why it doesn’t have content because it needs to be populated. It will be populated with JavaScript for each single of your pages, sort of pages.
Keira Davidson (21:20):
Yes.
Sara Moccand-Sayegh (21:21):
You shouldn’t really think about pages, but probably is the best way to explain it in a visual way if you want.
Keira Davidson (21:28):
Yes.
Sara Moccand-Sayegh (21:29):
So what happened? So you have this HTML page then is almost empty. And then you will have portion of the page then will change. And that will be the update. You will not change the entire page. You will change this portion of the page.
And an example, like the way then I finally understood it, because for me it was also, huh? So it was at the moment then somebody explained me, “But, Sara, you use it every day. Just check Gmail.” And then I was like, oh, that is it. Okay. Finally, I got it.
So if you use Gmail, you will realize then you will have new emails coming. But then you will not have … It will not update the entire page. You will just update the portion of the emails.
Keira Davidson (22:26):
Ah, okay. Yeah.
Sara Moccand-Sayegh (22:28):
And that is also how social networks works, for example. So if you use Twitter, then you can see it visually how it works also. And that is the logic of a single page app. So if you use Twitter, for example, you will have your tweets then update all the time. No?
Keira Davidson (22:28):
Yes.
Sara Moccand-Sayegh (22:28):
But not everything else.
Keira Davidson (22:28):
So it’s like the new-
Sara Moccand-Sayegh (22:43):
And that is the-
Keira Davidson (22:44):
Tweets are loaded in and they’re the new, they’re the change, and then the old tweets are just shifted down.
Sara Moccand-Sayegh (22:56):
Yes, exactly. So that is the way that it works. And that is like, so you have just portion of the page now updated. And to update this portion of the page, you have a method and this method is called adjuncts. So what will happen is that adjunct will have send a request to the server. And then you will get back your data, normally [inaudible 00:23:34], to update this portion of the page. I hope that was clear how it works.
Keira Davidson (23:42):
Yes.
Sara Moccand-Sayegh (23:45):
Okay. Whew, because that was difficult to explain. Okay. Whew. We did it. So now then we have the basic, now it became a little bit more complicated. So the problem is this, we have a single page app, but then we know from what we saw before, then URLs are super important. No? Because all the crawling system works through the URLs.
I would say, all the phase of crawling, rendering, and finally indexing. I mean, if you don’t have a URL, you have nothing. Okay?
Keira Davidson (23:45):
Exactly.
Sara Moccand-Sayegh (24:26):
So that’s mean then these are super important. But now we saw, then the problem was then in the single page app, we just change a portion of the page. So that’s mean then we are not having a response from the server. We are not having each time a new HTML, each time a new URL, and that’s make it more complicated. So luckily now single page app are a little bit more modern. Is that correct? The word modern in English?
Keira Davidson (24:26):
Modern.
Sara Moccand-Sayegh (25:02):
Modern. Thank you. So are a little bit more modern. And so what happened is then you will have your first request to the server and then you will have your answer, but then you will not have anymore really. In the past they contact with the server. Everything will happen on your browser.
Keira Davidson (25:27):
Okay.
Sara Moccand-Sayegh (25:28):
Everything will happen just on you browser. And this is something that makes special single page app. So everything happen in the browser. So is in the browser, then you’ll update also, you will have a lot of updates.
So when you have the single page app, you have a routing model. And they can act in two ways. So whatever I said, now, maybe you can forget it because it makes it a little bit more complicated. The only thing then you need to know is then you have a routing model and this routing model, what we’ll do is to help you with the URLs. To have URLs for your page.
Because if not, you will not have them. If not, you will always have, I don’t know, I work at Leap. Then I will just have Leap for all the page. Leap point ch for all the page. And that will be the problem. So you have this routing routine model then will help you.
And then you have two options. You have hash based routing history, API routing. Again, I will not explain it longer. The history API routing, you will speak to your developers because that is the method then is advised to use.
Keira Davidson (26:47):
Okay.
Sara Moccand-Sayegh (26:48):
Okay. Instead, and it will create the URLs the way then you can imagine URLs should be. Instead, the hash based routing method, what it will create is the hash. So for example, you will have like, let’s take again, my website, like the company that I work for. So Leap point ch, and then let’s say we want slash blog, for example. Instead of having slash blog, you will have an hash. Okay?
Keira Davidson (27:23):
Okay.
Sara Moccand-Sayegh (27:23):
And then blog.
Keira Davidson (27:23):
Yes.
Sara Moccand-Sayegh (27:23):
Okay.
Keira Davidson (27:24):
I think I’ve seen these.
Sara Moccand-Sayegh (27:27):
And that is bad. Why is bad? Because Google, that equals a fragmented URL. So the problem is then hash are, is way off sign to search engine. What come after that is not important.
Keira Davidson (27:41):
Yeah. Ah, okay. That’s interesting. I haven’t thought about that before.
Sara Moccand-Sayegh (27:47):
So yeah. So if you saw it now, maybe they did it on purpose or maybe not. Because normally, historically I think, I hope that I’m not saying something wrong. But historically I think then the hash was created, to jump from one part to the other one of-
Keira Davidson (28:05):
I’ve seen it-
Sara Moccand-Sayegh (28:06):
The page in their own.
Keira Davidson (28:07):
Yes, exactly that. That’s what I’ve seen. They might have do you know, at the top of a page they’ll have an executive summary and then they might have bullet pointed links. You click the link, it will then take you, let’s say to the bottom of the page where that content is. And that makes sense why they don’t care about it having the hashtag in the URL because it just gets ignored.
Sara Moccand-Sayegh (28:29):
Exactly. Because for that, it makes sense. Instead, if you want to go to another page with a completely different content, then you don’t want that.
Keira Davidson (28:29):
Exactly.
Sara Moccand-Sayegh (28:37):
Okay. I’m happy then you understood what I mean, because I was not so sure to explain it. Because it was looking a little bit complicated, but thank you so much. So, okay.
So now let’s think a little bit deeper. So now we have this URLs. But now what we know, we have some golden rules. What we know is then to index the page, Google need unique URL. So that we cite, we saw why. So that’s mean then when we generating URL, it needs to be unique. Ensure all links have a hash ref. Okay?
Keira Davidson (29:17):
Yes.
Sara Moccand-Sayegh (29:17):
So it means then you need your HTML mark cap with hash ref. Google was very vocal about that. They never hide it. They say, “You shouldn’t have an hash ref. We don’t even recognize it.” So, okay. So now we know you need an hash ref. There were several very creative way of writing links. Now we know then all these creative ways, they are no go.
Keira Davidson (29:44):
Yes.
Sara Moccand-Sayegh (29:45):
So, okay. So we know then we have a unique URL. We know then we need an hash ref. So the HTML cap. We know, then we need a target URL. Okay?
Keira Davidson (29:58):
Mm-hmm.
Sara Moccand-Sayegh (29:59):
What we also know then when you’re using a single page app, then you should use the history API and not the other method and create the fragmented. Because we know then fragmented is no, no, no, no. Okay?
Keira Davidson (29:59):
Yeah.
Sara Moccand-Sayegh (30:13):
So this is exactly what we know and how we should apply everything. So that’s mean then the only thing that we need to keep in mind, if we don’t see a URL with hash ref, and then the page then you want, and better, if there is the actual text, then it’s the wrong URL. Then something is wrong in that URL. So the good URL is that one.
And if it is in the final HTML, is perfect. It just shouldn’t be hidden. Everything, we also have to remember, that Google don’t click. So if you need to click something-
Keira Davidson (30:55):
They’re not going to find it.
Sara Moccand-Sayegh (30:59):
Have it. Yeah. It will not exist. So that is important. So now we know a capital thing about how single page work. We know how we should write a link. And that is the same logic also for single page app and not single page app.
Now single page app, obviously, because they’re single page app, they have an extra particularity. So we have site then. So let’s repeat it just to make sure. We have one request to the server. And then everything else happen in the browser. Okay?
Keira Davidson (31:44):
Yeah.
Sara Moccand-Sayegh (31:45):
So when happen in the browser, we say client side rendering. So the client side routing, the routing was that stuff then was taking care of the URL. The routing then will take care of the URL, as we said before.
Keira Davidson (32:01):
Yes.
Sara Moccand-Sayegh (32:02):
And the problem is that, as we said, we have a response code. The response code will always arrive from the server. But everything is happening in the browser and we don’t have anymore. They contact in a certain sense with the server. So we have a problem. Because if we have a 404, it should be the server, and server say 404.
Keira Davidson (32:30):
Yes.
Sara Moccand-Sayegh (32:30):
And then we don’t see the 404 for a single page app. Then there is Google, if you check the documentation about fix a JavaScript problem. I don’t remember exactly what was the name of documentation. But again, there, you will find some solution to this problem. And if, when you discuss with the developer, if they’re using single page app, just remind them, then they have to generate 404.
Keira Davidson (33:07):
Okay.
Sara Moccand-Sayegh (33:09):
It’s important. Because for us in SEO, we know we need to keep control on the 404. We want to know if there is a 404.
Keira Davidson (33:09):
Yes.
Sara Moccand-Sayegh (33:19):
And then that is important. Then to complete this part of the discussion, there was like, Jamie [Alberico 00:33:30]. She is so smart. Now she always have smart questions. And one of the question then there was this video, JavaScript SEO [inaudible 00:33:42]. And then she asked it in the video, what abouts adjuncts? How that affect crawl budgets?
So I don’t know if you remember what we say at the beginning, but so at the beginning, between, to change the portion of the website and we want to change, we use this method. And the method then we use to change the portion is adjuncts.
So this method is the contact with the server in a certain sense. So the process of sending the request to the server and bringing back the response without reloading the page. Because that is the key, not reloading the page.
So that’s mean then we have adjuncts and we are using this method. And then we still have a lot of request because we have to be in a complete web page. So before I give the answer on that, then I saw it on the video obviously. Let me just make clear for everybody, what is the crawl budget? Because maybe the most easy way to understand the crawl budget is how much reserve. I say reserve.
Keira Davidson (33:19):
Okay.
Sara Moccand-Sayegh (35:14):
I can do it. How much reserve the server hosting the site can allocate to crawling? Okay?
Keira Davidson (35:24):
Yes.
Sara Moccand-Sayegh (35:24):
So the problem is this, when you have too many requests, you don’t want to shut down your server. So obviously Google will be also careful how your server is the same server. Yes or no?
Keira Davidson (35:42):
Yeah.
Sara Moccand-Sayegh (35:42):
So if it is the same server, you will have many more requests from Google. So it means then at a certain point, we will have a limit. Also, because it can’t spend the entire night on your website because it needs to take care of the entire web. And plus there is the problem of your server. Okay?
Keira Davidson (35:42):
Mm-hmm.
Sara Moccand-Sayegh (36:07):
So how adjunct affect the crawl budget? So there was this example, if I’m not wrong. Yeah. There was this example. So say you have adjuncts for a product page. So what you will use is you have one request, but then you need to supplement your piece of contact for the product page.
So instead of just having one request, you will have nine extra request. So you think then you have one request, but then you have to supplement entire page, or the product page. And then each time is a request. Another request, another request, another request. So at the end, you finish to have 10 request to supplement your page. Okay?
Keira Davidson (36:58):
Yes.
Sara Moccand-Sayegh (37:00):
So that’s mean then you’re using your crawl budget. But, and this again but, as Google always say, we cache aggressively. As a result, that will happen just the first time. The next time they will have already cache all the information. So they will not need each time to do the same thing. So the next time then they will come back, they will ask for less crawl budget. Okay?
Keira Davidson (37:36):
Yes.
Sara Moccand-Sayegh (37:37):
But again, it doesn’t mean then you need to throw away your crawl budget. Especially if you are a large website, last thing then you want to do is throw it away like if it is nothing.
Keira Davidson (37:37):
Exactly.
Sara Moccand-Sayegh (37:52):
So anyway, be careful. And then, so it was a little bit complicated, this part. And then what as a SEO, we can do, as we say before, we were speaking about the testing tool for in general, and that could be applied on the single page app to use search consult, mobile finding test.
You can always use the site command if you want to check. So a little bit manually, I always taking the content. So you can always use that on Google and check if it’s taking the entire content of your page. Especially for the product page, maybe you want to check.
Keira Davidson (37:52):
Oh, wow.
Sara Moccand-Sayegh (38:35):
Okay. I don’t know how much time do we still have? This we decide if we go to the next meet, or we switch a meet, what do you think?
Keira Davidson (38:45):
As much as I’d love to go on, I think maybe we could potentially revisit this again in the future. For now, it’s been great speaking with you. I personally now actually understand SPAs. I didn’t realize that I’ve come across them in the past without even knowing it. It’s been great speaking with you. I’ve had great fun and I’ve learned so much. Thank you.
Sara Moccand-Sayegh (39:12):
For me, it’s super to speak with you. And it is really a pleasure. Yeah. You’re an incredible host.
Keira Davidson (39:12):
Thank you.
