Hi, everyone, and welcome to today's Google Search Central SEO Office Hours. My name is Jamular. I'm a search advocate on the Google Search Relations team. And part of what we do are these Office Hours hangouts where people can join in and ask their questions all around search and their websites. So many people joining us today is fantastic, cool to see a bunch of new names and faces as well. So that's always neat.  But as always, maybe we can get started with some first questions. And I think what probably works easiest is if you're live in here, just use the raise hand feature. And then I'll try to go through in that order. And wow, OK, lots of people are raising hands already. OK, Praveen, maybe you can get started with your question. Hey, hi, John. How are you? So it's a bit weird and a long question, so please don't mind. There is this website we have, which is a global website. And they have pages in multiple languages, in English and Japanese and Korean. So this website has implemented HRF and tags and all that stuff. And they're doing pretty good in Google in all the local regions. And the problem is that in South Korea, there is a local search engine called Naver. And Naver has a problem with these HRF and tags, like it doesn't understand them. And this website has these languages, like they have used directly system, folder system, for multiple languages. They are not using subdomains or separate domains. And this makes even harder for Naver to understand that this website is in multiple languages. So the solution, what it does is it shows English version to the Korean audience for Korean queries. And that's the problem. The management had decided, why not we should make a separate website for Korean audience in only Korean language? And the concern from Google's point of view is that if we allow that website to be indexed by Google too, can that new website impact performance of the existing global website? Is there a possibility that, because Google can figure out that both these websites belong to the same domain and they are basically targeting the same audience. But that new website won't be just copy paste. It will be a website with new user interface, new fresh content, and everything will be new. The only concern is, can the new website impact performance of the existing website? Because that existing website is doing pretty good on Google. I think if it's a completely separate website, then it's a completely separate website. So that's no concern from that point of view. If it's just on a different domain and it's essentially a part of the same set of pages, you can still use hreflang between those different domains. So hreflang doesn't have to be just within one domain. So that might be another option where you could say, well, they don't understand hreflang, but if it's on a different domain that works for them and Google understands hreflang and can do it between domains as well, then you can combine those two options. We actually don't want to confuse Google with, like, we have so many pages on the system and then one is on the subdomain. So we just want to keep things simple. So the only concern new websites should not impact the performance of the existing website. I think that's clear. Yeah, I think what will happen is you will compete with yourself, with your existing website. And if you're OK with that, that's fine. But it sometimes makes it a bit harder to rank well for some queries, because both of these versions will have some amount of signals and value in Google's eyes. And that means maybe both of them will be kind of mid-range with regards to ranking. But if these are queries where your site is very visible anyway, then probably it doesn't make a big difference. But essentially, that's up to you. It's not that the WebStream team will look at this and say, oh, two websites is too much. Sure. Thank you. Thank you. Sure. Xiao Qian. Oh, may I not pronounce your name? Sorry. Thank you. Thank you. I also type my question here. So my question is, a while ago, I was reading one of Google's guide. They say that do not index internal search results because you generally not search user intent well. I agree with that if it's an informational site because people won't be landing on the page that directly answer your question. However, I'm not quite sure it's also the same for e-commerce site. For example, when you are searching for, for example, slim computer, and the first result is actually Amazon's internal search result page. And as a customer, I won't be happy seeing that because it did provide a lot of options for me to buy. And so my question is just that for very transactional intent keyword e-commerce site, it's also not recommended to index internal search page. So I think that's something where you could argue that these are more like category pages or where you could say, well, it's more like a category page and it's indexable. The tricky part with internal search pages is that it's often an infinite space in that you can enter any random word and it'll create a web page for it. And that's something you kind of want to avoid. But if there are specific topics where you say this is kind of like an important topic, then you can definitely keep that indexed. It's not that the Webstone team is reviewing these and seeing, oh, internal search, it should be spam, kind of thing. It's more a best practice for crawling and indexing that you provide pages that are useful for users. And if these are internal search pages that are more like category pages, that's fine. I see. Thank you so much. So would you recommend only pick some of those internal search pages to index while blocking the majority of them? Yeah, I think if you can do that, that's what I would do. Like take a list of keywords where you're saying these are OK and everything else just block those. Just to avoid the situation that people create random pages for random words or also what I've sometimes seen is people create pages for words that you don't want to rank for. Like, I don't know, maybe they're searching for medical terms and your website is about computer products, then you don't want to rank for that content. I see. Thank you so much. Sure. David, I think you're muted or your microphone is not working. Yes, no, I was muted. Sorry. Thank you. OK, I have a few questions, but I think they're quick. So I'll try to get through them. Number one is, if enhancing core web vitals, let's say it reduces the, we get rid of a bunch of old scripts and reduces the page size in half, would that correlate with an increase of crawl rate budget? Maybe, maybe. So there are two things there. On the one hand, if we can access your HTML pages faster, we can probably crawl more. So that would go into the crawl budget side of things. The other part is, if we can render your pages faster, if there are JavaScript pages, then we can also get through them faster. But it all depends on the demand as well. So for crawl budget, we have the capacity of the website and the demand from our side. Got it. Now, the other question is a little more difficult. Basically, there's the amount of pages that are being indexed by Google in the coverage report. And then if I go to the internal link report in the link section, I see that all the links that are in the header and footer are the top ones with the same number pretty much. So I know that it's collecting those as internal links to report on, regardless of its effect or impact. But the number is a tiny fraction of the total index pages. And when I do a site search in Google, it's somewhere around the range of the total index pages in the coverage report. But then I go to the internal link section, and I'm talking about indexed is 6 million. And in the internal links is 30,000 for all of those header footer pages. And those are on every one of those pages. So what would that hint to me? Nothing really useful, probably. It's just for these reports, we take a sample of the pages from your site. So they're not meant to be kind of on the same level as the index coverage report. Got it. So it's just to get an idea of which internal links are found more often than others. Exactly. OK. And then the next thing is she mentioned it about the URL parameters for search pages. If you're dealing with a site that the search is set up that it auto corrects and redirects to a proper search that we want that's in our site map that's relevant, is that a redirect that will hurt in terms of crawl budget? Because it could be anything. Someone could input anything, even though we'll find the right page, probably the most relevant on the site. Is it going to impact anything? And how would be the best way to implement? How are you redirecting there? I would have to speak to the dev team, but I don't know. They have their own internal link system algorithm. So usually with redirects, we follow, I think, a small number of redirects immediately. And it's kind of seen as a part of the same request. And I think the limit is something like five, something like that, where if there are five redirects in a row, we'll just follow that and look at the final content and treat that as one request. If it takes more than five steps, then we would treat that as separate requests. But usually for something like this, you would have one step. And you'd be kind of on the category page or something like that. And that's perfectly fine. OK. All right. Thank you. All right. Evan. Yeah, so I think I was a little faster on the hand but my colleague, Derek, could probably explain the question more succinctly than I can. Derek, if you want to go ahead. Sure. Can you hear me? Yes. Great. So our question has to do with core web vitals. I'll post it here in the chat. Basically, we want to know how it relates to AMP. So we have enhanced our site for AMP. And 90% of our mobile traffic goes to AMP pages. But now we're addressing core web vitals stuff. But in our core web vitals dashboard, it looks like only 50% of our pages are hitting good marks there for mobile. So we spend a lot of time doing AMP. Are we going to be penalized for the pages that we have that are not AMP that are performing poorly on the web vitals side? I don't think you would be penalized for that in that sense. But I mean, what happens on our side with regards to the core web vitals is we use the Chrome User Experience Report data as kind of the baseline. And we try to segment the site into parts what we can recognize there from the Chrome User Experience Report, which I think is also reflected in the Search Console Report. And based on those sections, when it comes to specific URLs, we will try to find the most appropriate group to fit that into. So if someone is searching, for example, for AMP pages within your site, and you have a separate AMP section, or you have a separate AMP template that we can recognize, then essentially we'll be using those metrics for those pages. It's not so much that if there are some slow pages on your site, then the whole site will be kind of seen as slow. It's really for that group of pages where we can assume that when a user goes to that page, their experience will be kind of similar. We will treat that as one group. So if those are good, then essentially pages that fall into those groups are good. The tricky part, I think, with the AMP Report is that we show the pages there, but we don't really include information on how much traffic goes to each of those parts. So it might be that you have, let's say, 100 pages that are listed there, and your primary traffic goes to 10 of those pages. Then it could look like you have all of these 90% or slow, perhaps if those 90 other pages are slow, and those 10 that people go to are fast, but actually the majority of your people will be going to those fast pages, and we'll take that into account. So two follow-up questions there. One, you mentioned that you segment these results into different sections, right? So when I look in the Search Console, you're right, I can see that they're grouped together, but I see the AMP and the non-AMP pages separately. So will you take into, if you do a search result and I have maybe a site that's not AMP canonical, but you're showing an AMP result for, will it use the results from the AMP section of that page, even if the search result itself is for the non-AMP version, it has the AMP enhancement? Sorry, does that question make sense? I just kind of got confused with that last part. It's like it's an AMP page, but we're showing the non-AMP page? Well, so there's an AMP and a non-AMP version, right? And in the search result, you're showing the AMP version, but it's not AMP canonical, so it is my, if that makes more sense. Yeah, I think what, I kind of have to look at the specific situation. My understanding is we would follow the canonical and use it based on that. Okay, so if usually we would like, yeah, I mean, usually what would happen is we would fold the AMP information, the AMP signals, into the canonical itself. Got it, okay. And then I guess the second follow-up question is, does the AMP results in the Chrome user experience reports take into account the benefits of the AMP caching? Because I can imagine just like going to the AMP page would be much slower than viewing the cached version from that. We, I mean, what we do is we take into account what users see. So if it's a valid AMP page and we can serve it from the cache, then we'll use that. Whereas if it's a kind of not a valid AMP page and it's still an AMP page and pretty fast, but we can't serve it from the cache, then obviously we don't use that. Yeah, totally, I was just asking because the Chrome user experience report I know takes from like just people browsing the internet from Chrome, so I don't know, I wasn't sure if I was able to associate the cached AMP pages with those origins. So that was my question, thanks. Cool, fantastic, next. Hi, John, another AMP related question. If we're changing AMP URLs, do we need to redirect from the old one to the new? So the canonical URLs are staying the same, we're just changing the structure of the AMP URLs. Ideally, yes. In practice, it's not as critical as with normal URLs on a website. Because usually what happens with the AMP URLs is we refresh the cache fairly quickly and we will notice that the canonical URL and the cache page and those URLs change fairly quickly. So it's more something where I'd say you have that time period between when we know about the URL, when we show it in the search, and when we've updated it, which might be, I don't know, a couple days' time. So it's definitely less critical than with the normal pages, but ideally, you would still redirect those as well. OK, and I have a second question for AMP again. So I think it's been stated a few times that there isn't a direct ranking boost, a ranking factor from AMP. However, last year, we removed our AMP pages, we redirected AMP URLs to our canonical pages, and then we saw a decrease in traffic straight away. And over six days, it was 10% decrease in organic traffic. So we redeployed it, we turned it back on because we didn't want to keep losing traffic. Is there an obvious reason why that might happen? I don't know. It kind of depends on the site. So on the one hand, I think there might be an effect of things just kind of like still pointing at the AMP pages and kind of getting lost if you just turn it off. So that's something that would be something more of a temporary effect. That's something you can also try to mitigate by using the AMP cache API, I think, where you can force a refresh so that we can see these AMP pages actually no longer exist kind of thing. I think we have a Help Center article on Disabling AMP, actually, that covers all of those steps. The other effect that you might be seeing there, depending on the type of site, is that for certain search experiences, search features that we show in the search results, we do use AMP. So I think that's in particular the top story section on mobile where we essentially require AMP pages, at least at the moment. And if it's a news website, for example, that has a lot of content that is shown in the top story section when it's on AMP, then you will see that kind of disappear. That's something where with the update that we're doing in May around core web vitals and page experience, we're going to start allowing normal pages as well when they reach that appropriate bar to be visible in the top story section. So that'll be a little bit more mitigated. But it really depends on the kind of site. Like, if it's not a news website, if there's no kind of newsy content on there that would have been featured in the top story section, then it would be kind of weird to see a drop in overall organic traffic. OK, yeah, it's not a direct news website, per se, but it's a medical article website. And we do feature in the carousel, AMP carousel. So yeah, that would be nothing. Yeah, yeah, that could be. Cool? OK, that's good. Mohammed. Hi, John. Hi. I work in an IT company. We put lots of tons of quality content at our website. But recently, we got to know that there are a few websites that have been copying our content and publishing it on their website. In fact, they are not making an effort to change the images. So I just want to know what kind of action we can take or how does Google consider these kind of activities and how we can protect ourselves in future regarding these fraudulent activities? I think the primary action you could take there, depending on the situation, is to look into the DMCA process. The DMCA process is a legal process. So I can't give you legal advice on when it applies and when it would not apply. But that might be something that you could look into. With the DMCA process, you're basically saying, my content is my content, and someone else has copied it. And you're giving Google that information on a per page basis. And based on that, our systems or the legal team, I don't know the details, will review that and take action on that and also inform the other side about that so that if, for example, they were the original source, they would be able to raise a concern and try to find a different resolution for that. But that's, I think, the primary approach that you could take there. The other thing that I would also keep in mind is that if you're regularly seeing other people with copied content ranking above your content, then to me, that points at a situation where maybe the overall perceived quality of your website is something that our algorithms are having trouble with. That could be something where maybe it makes sense to take a step back and think about your website overall and try to find ways to significantly improve the quality of that to make sure that when our algorithms run across your website with the content on it and some random website that they don't know about with the same content on it, that they say, well, actually your website is the one that we should trust. And not so much like some random website is perhaps just as good or even better than this website that we know about that we know we don't want to trust that well. So that's kind of a different thing to think about there. But I would definitely look at the DMCA process first. And also, if you're regularly seeing this, I would really think about what you can do to improve the quality overall. That means that we have a loophole in our own website. How do you mean? Like we are not up to that quality. That's why other websites are copying our content. I don't know why other people are copying your content. I can't say. But if you're regularly seeing that the copied content is ranking above your content, then to me, that would point at some kind of quality worries that our algorithms have. OK, thank you. Sure. John, Darcy. Hi, Oriel. Back in, I think it was mid or late February, a couple of the tracking tools were reporting some drops in featured snippets and the amount of times that those showed up. Judging by your reaction, I don't know if you are familiar with that at all. Just wondering if that was deliberate by any means on Google side to reduce featured snippets from showing up, or if it was maybe for another reason that that might be happening. It's just featured snippets, when you get them, are pretty awesome. And to lose them is pretty disastrous. At least you've been used to riding this wave of traffic that can come with a featured snippet. So to lose it, yeah, just wondering if there's any additional rationale, or if you know of any maybe it was a side effect of another change. I don't know. I don't know. Like the featured snippets and the rich results in general, those kind of things can fluctuate over time. And I know the teams are always working on those features and trying to fine tune the triggering. So when we would show them or when we wouldn't show them, sometimes the triggering changes over time, that we just kind of reduce the threshold overall, or that we change the focus a little bit and say it's less here and more here. Sometimes that happens across geographies or languages. But these kind of changes from our side are essentially normal organic changes in search, how they can always happen. So it's definitely not the case that we say, well, like there's some technical requirement that's missing on these pages, therefore we dropped it. It's more we need to refine which types of results we show over time. So yeah, just more of a balancing act, I guess. Yeah. So would you think that it was a deliberate kind of reduction in featured snippets, or maybe some other change that might have then caused that reduction? Any idea, yeah. I don't know. I don't know. Usually we don't think of it as much as we want to reduce the number of times we show a feature, but rather we want to improve the targeting and the relevance of when we show the feature. And sometimes that does mean overall it's fewer, but it might be that they're fewer here and there's a little bit more here kind of thing. And that's something that it just happens over time. They're always trying to find a better balance of what to show in search and improve that. Gotcha. Cool. Thank you so much. Sure. Clint. Morning, John. My question relates to the mobile index and specifically a responsive design. So if, for example, there is an element on the page which links to, let's say it's a online catalog or something like that, so that component on the page is essentially linking to the catalog. The catalog itself is not mobile friendly. So as a result, under the responsive design, we would basically hide that component, but essentially it's still part of the DOM. So under the new mobile index, will this content still get called an index? Or because it's not rendered on mobile, it's basically not getting called an index? If it's in the DOM, then we would be able to pick that up for indexing. So that would be perfectly fine. I can only show up then on desktop potentially not on mobile. Yeah, yeah. Sometimes what we try to do is figure out which parts of a page are visible and kind of emphasize those with regards to ranking. But especially on mobile, we see that there's a lot more interactivity on a page in that you kind of activate different tabs, you kind of see different things, and actually it's all a part of the same HTML page. And from that point of view, if it's not visible but it's in the HTML in the DOM, then that would work for us. All right, thank you. Sure. All right, SEO team. Hello, everybody. How are you? I am very interested in that. I can talk with you, John. I was waiting for this online session because of a particular reason. I have four more important questions for an execute purpose, but the four questions are somehow big. Then I will ask the first two questions. I wish that I can get sometimes during the session to ask the remaining questions. First of all, for websites that have AMP pages and non-AMP pages, how we can measure the core of vitals to get a general idea about the whole performance of the website? I mean that, do we need to measure the performance of AMP pages alone and the non-AMP pages alone? What is the best practice here? So depending on the way that you have the AMP and non-AMP pages set up, you may be able to see the difference in Search Console or in the Chrome User Experience Report data because that could be split out by URL. So I would double check that. The other thing that you definitely can do is do lab testing, especially if you're modifying pages, if you're trying things out, then I would do lab testing with page speed insights with Chrome directly in the browser to test things, especially to compare different versions of the same page. And when it comes to lab testing for AMP pages, if it's a valid AMP page, then definitely also check it on the AMP cache to see what users would see when they click on a search result. And that's the approach that I would take there. I also recommend when it comes to testing that you set up some kind of a monitoring system on your side to regularly test the important pages on your website for the core web vitals so that you are able to recognize quickly when something goes wrong. But that's more of kind of like the long-term thinking. OK, thanks a lot. Another question is that I found a lot of difference between Google Analytics and Google Search Console data. For Google Organic Traffic, I read a lot about the causes of such a difference. And I know that each tool has its own algorithm in collecting and measuring data. But we are facing a lack in reading our Google Organic traffic, in which we have some articles that get thousands of clicks on Search Console. But Google Analytics shows that it's only have 10 or 20 Google Organic traffic, sure for same date range and the same article. More than that, in Search Console, sometimes we see articles that have an increasing curve for a number of clicks. But Google Analytics show a decreasing curve for Google Organic Traffic. So while we are seeing that and is there any step-by-step guide about how we can solve the big difference in data between Google Analytics and GSC? I don't know. So that's something I would check with the Analytics team and with the Analytics Help Forum to get some input there. The one thing I would kind of suspect, but I don't know how it's implemented on your side, is since you mentioned AMP pages, it's possible that the AMP pages are being tracked separately in Analytics. So depending on how you have AMP set up, it might be that you have a separate property for the Analytics pages, and they're kind of separated out. Whereas in Search Console, we focus on the canonical URL, so we would show all of that traffic together. So that might be one reason, but I would really get some tips from the AMP Help Forum. Yes, yes, Jun. Analytics Help Forum. Yeah. But sorry, sometimes we saw a vice versa data. We saw that Google Analytics show data more than the real data on Google Search Console. Not every time Google Search Console show data more than the number of organic traffic at Google Analytics. Yeah, I don't know. So the tricky part is Search Console can track what happens in Search, but doesn't know what happens on your website directly. And people can go to your website directly with a referrer from Google, and it can look like someone is coming from Google Search. But in Analytics, you can't tell, is it really from Google Search, or is it someone just using the wrong referrer? This kind of weird behavior is pretty common. It just happens on the web. So sometimes you do see some discrepancies, but especially if you see a lot more data in Search Console than in Analytics, then to me, that feels like something in Analytics is tracking wrong. OK, OK, thanks a lot. Sure. I don't know if I'm pronouncing your name right. Hey, Joan, how are you? Hi. Actually, I have a few questions related to schema. Actually, I have implemented schema marker for knowledge panel graph on my website. But still it is not appearing knowledge graph. Please let me know which factors we need to consider to implement knowledge panel graph for a brand. Please let me know. Yeah, I don't think there's any specific markup that you can use to force a knowledge panel to appear for a brand. So what you can do is give some general company information, like the logo, like address, opening hours, things like that. But just because that specified in structured data doesn't guarantee that we will show a knowledge panel entry. Sometimes what you can also do is the Google My Business entry, which also appears in the side similar to a knowledge graph entry. So that's something where you can try different approaches there. But it's not that there's one structured data type that forces the knowledge panel to appear. OK, another question is related to site links. Actually, I need to appear some desired pages as a site link in Google SCRP. But still, I'm trying from last six months, and I have lots of activities. But still, my desired pages are not appearing as a site link in Google SCRP. Please let me know what can I do for this. So site links are generated automatically as well, kind of like with a knowledge panel. And there's nothing specific that you can do to force those. We try to pick up the site links based on your site's internal navigation primarily. So if we can understand how people can navigate your website better, then we have more of an opportunity to show site links. But it's not guaranteed that they will be shown. And for most websites, I think we just don't show site links. OK, OK. And what we can do to appear site links such walks, which appear just. Yeah, the site link search box is something where you can add structured data to your pages too. But the structured data is only used when we show the site link search box. And it's similar to site links in that for a lot of sites, we just don't show the site link search box. I think it's a confusing feature because of that, because you can add markup. But the markup only has an effect if we would already show something for your site. OK, we can't depend on the schema markup for it. Exactly. OK, OK. Thank you so much for the information. Sure. And then Kit, probably pronouncing your name wrong. Sorry, I think you're muted. Now what button? Yes. OK, hello, John. Perfect. Hi. Yes, OK. I have a question. My website has a problem with redirects. Sometimes I make a mistake in the conversation. It's really hard to. My example. Yes. My URL, my website is Ho Chi Minh City, content of HON, HON about information about Ho Chi Minh City, and canonical Ho Chi Minh City. And I have different URL in Ho Chi Minh City and paragraph ID, district 1, Simone content, district 1. And other URL, digital bus URL, canonical, to Ho Chi Minh City. Yeah. Yes. New URL in Ho Chi Minh City and canonical Ho Chi Minh City. OK, district 1. Yes. Bus when I, if I redirect 301 from our URL to new URL. Exactly. I have any problem with my website for Ho Chi Minh City. It has my, I have a problem when I redirect 301, OK. OK, so you're redirecting a part of your website to a different part, is that? Yes, yes, yes. When, yes, to a clean URL, to a clean URL. To a clean URL, OK. Yes. Will my URL Ho Chi Minh City will have battery stored on Google or any problem? OK, you understand? Yes. A little bit. It's hard. But in general, when you redirect from one URL to another, we try to forward all of those signals. So if you have links to the old URL and you redirect the old URL to a new URL, a cleaner URL, then we will forward all of those signals and all of those links to the new URL. So that's, I think if I understand your question correctly, we would pass all of that information to the new URL. The all URL, which parameter? Yes, which parameter, a district one or district two. But it's kind of difficult to just Ho Chi Minh City. If I pass it, it means I redirected Ho Chi Minh City to many URL. Is that right? Yeah. I think, so I'm having trouble understanding exactly the configuration for your website. But in general, if there are parameters with the old URL, that's perfectly fine. We can also forward that. If you have other URLs on your website that you're not redirecting, then that's also perfectly fine to just keep them. So that should, I think, just work. If I understand your question correctly. John, the question is also in the chat. I think it's much more clearer with the structure there. I think it's the case that there are some district-related pages that have canonical to the main city page. But the new structure includes a separate district page as their own pages. So what would happen if those parameter URLs are then redirected to the new district pages if they had a canonical until now to the main city page? OK, so basically taking a set of city pages and redirecting them to one general page, more general page. No, I think there was a general page in the beginning with a few parameters for each district that had all of them had a canonical to the main city page. But now there will be separate pages for each district. So if until now every parameter URL had a canonical to the main city page, and now there are separate pages for each district, if they redirect from the parameter, from those parameter pages to the new district pages, if that will affect the main city page, I think. As I understand it, it's like we would follow these redirects on a per page basis. And if there are individual redirects there that take place where you have multiple pages redirecting to one page, or you have individual like this parameter URL redirecting to one clean URL, and you have other pages that stay the same, we would all look at that on a per page basis. So I think if you're cleaning things up, like for a handful of pages for different sections of your website, that's perfectly fine to do like this. That's workable. It's OK. It's no roll up. Yes, thank you, thank you. I have one question. My website is Classify website. It has 100,000 content. Yes. After two months, this content has over time. It means someone buy a house, someone buy a motorbike. When they boss to my website, just two weeks or one week, they saw this. My question is, if the content is too old, what should I do with it? I delete it in my website, or I keep it on my website. Keep it. Yeah, that's a very common problem. If you have a kind of classified content, then it comes and goes fairly quickly. There are two approaches that people take. And for us, they are very similar. So one is to say, the old product that no longer exists, or the page that no longer exists, redirects to the category page to us that would be seen as a soft 404, which is something we discourage, but for users, maybe it's OK. The other is to just say, this page that no longer exists returns a 404 error, and then we would just drop that page. So in practice, in both of these cases, the old page would drop out of the search results, and we would be able to focus on the rest of the website more. So the only thing I would not recommend doing is for the long run, keeping the old page and just adding a label on top saying, oh, this is obsolete. It's expired. Because then you have a lot of pages on your website that Google has to crawl, and first recognize, oh, there's content here, but it says it's expired, so I can ignore it. So that's what I would avoid. But redirecting or 404 is fine. Oh, OK. Thank you, thank you, thank you so much. Thank you, thank you. All right, Mihai. Hey, John. By the way, regarding the question in the chat, I think a more general, I mean to put it in a more general way is when you have a lot of URLs doing something, like they all have a canonical to a certain page, and then you change it, and all of those URLs no longer have a canonical, but they do something else. Maybe they're just indexable. Maybe let's say you have an e-commerce website, and you have a category page, and all of the filters or something like that, they all have a canonical back to the main category page. But then you decide, OK, I need those filters to be indexed or redirect them somewhere, I don't know. And you break the canonical, and then you use them in whatever other way you want to use them. Does that mean that the main category page starts to lose some of the signals that were, until now, aggregated from all of those filters and things like that? Is it kind of a balance? You kind of gain some, you lose some. Probably. I mean, it depends a little bit on what you mean with signals, because with a canonical URL, when you specify that, we don't take the content itself into account. So if you have a blue car, and the canonical is a green car, then we will index the green car, and we won't know about the blue car. If someone links to the blue car, then we know there's a link that indirectly goes to the green car, but we don't know it's like blue car. Right, but that means that if you start making the blue car indexable or do whatever else with it, that means that the blue car will start gaining maybe in rankings and get traffic, especially if it has links and everything else. But you're no longer canonicalizing to the green car. So the green car kind of loses those ranking signals that came through the canonical until now. So you lose some, but you might get a lot more traffic by being more specific towards certain queries. I think that's always a balance that you have to figure out, like there's no absolute answer where you can say you should always split it up or you should always combine it. Sometimes it makes sense to split. Sometimes it makes sense to keep it separate. I guess it's a lot based on what your users are really interested in. And if they're looking for something more specific and you have a page that could provide a better experience for them, then that might make sense. So I want to ask very quickly about something regarding Core Web Vitals in Search Console, because the Core Web Vitals are taken from the Chrome user experience report. So the data in Search Console is taken from the Chrome user experience report. Yet for, let's say you have a CLS issue with a bunch of your pages, you have the option to validate fix. But that doesn't make as much sense as you would validate fix on a coverage report, because it doesn't matter if Google recroses those pages. The data is not from Google, but it's from the Chrome user experience report. So that's a bit confusing. Yeah. We have that there for consistency reasons, but it's based on, like you said, like the Chrome user experience report data. So it wouldn't be the case that we would be able to say, more people should click on this link, and then we have more data to look at. We basically have to wait for things to update there. So it's just a kind of a display report thing that the validate fix actually helps you just kind of see it. Exactly, yeah. OK, makes sense. Cool. We're running low on time, so let me just go through some of the questions that were submitted that we didn't get to yet. And I'll stick around a little bit longer if anyone wants to chat for more as well. The first one I have on top is about AMP. I think we talked about that, also AMP to ranking factor. Will Google consider the origins field core web vitals data for the whole domain, or will it be ranking on a per page basis? We talked about that a bit as well, kind of the different groupings that we show. How accurate is crawled currently not indexed in Search Console despite being a page with sufficient content, without issues. Many pages are excluded from the site from being indexed. That's fairly common. So for the most part, we don't index all pages that we know about on a website. We have to prioritize a little bit. So that's something where it's less a matter of, like, this individual page is fantastic, but more that we need to understand that there's a lot of value to be gained from showing your website more visibly in Search. And that's something that's more of a long-term process, unless something on a per URL basis, where you can say, this page is good now. For passage indexing rolling out, does passage indexing relate with core web vitals for ranking or indexing factors? No, that's something completely separate. Also, passage indexing is kind of a bad name. I hope the people who decided on calling it indexing don't listen, but it's not based on indexing. So nothing changes with indexing. It's really based on ranking. So understanding what is on a page and how to show that in the search results. Does the URL parameters tool in the old Search console still work? When will the new version go live? Yes, it continues to work. I don't know of any date with regards to a new version. I think that's one where we're talking with a team to figure out what the right approach is there. And it might be that at some point, we decide, well, it still works, but it's not as valuable for all users to actually migrate to the new version of Search Console. And maybe it'll go away at some point. Maybe it'll be migrated in a different way. Maybe it'll be taken over one to one. I don't know. How do the core web vitals interact with AMP site enhancements? I think we talked about this as well. We have two regional sites under different subdomains, one in German for the German region, one English for the US. We kept the URL handle of our products the same for easier forwarding, but this means that the URLs in our US store are in German. Is this a problem for search ranking in the US? No, it is definitely not a problem. We use the words in a URL as a very, very lightweight factor. And from what I recall, this is primarily something that we would take into account when we haven't had access to the content yet. So if this is the absolute first time we see this URL, we don't know how to classify its content, then we might use the words in the URL as something to help rank us better. But as soon as we've crawled and indexed the content there, then we have a lot more information. And then that's something where, essentially, if the URL is in German or in Japanese or in English, it's pretty much the same thing. The only effect where I would worry about this a little bit is that users might be a bit confused if they're copying and pasting your URL, if they're recommending it to other people. Then if the URL is in German and it doesn't make any sense at all to them, then that might be something where they're like, what is this URL actually about? Usually if it has product names in there or descriptions that have very similar words in English and German, then that's less of an issue. But if the URL were in Japanese and the users were in the US, then that could be something where they're like, what am I actually forwarding to my friends here? But that's not an SEO factor. That's more of a marketing issue. I work on a big news site, and some parts of the articles are blocked from the user until they click the Read More button. For the Google user by default, let's say it's not blocked behind a login page when we show Google about the whole article. So in general, I don't think this is really problematic, but it might be worth thinking about whether or not this should be used with the paywall structure data, where you can clearly specify this part of the page is visible by default, and this part isn't. I think probably paywall would be not perfectly suited for this. And probably if this is really something where you just click a link on a page and then the CSS switches over to show more content, then that feels like something where from Google's search point of view, we wouldn't really care. It might be that your users are a bit annoyed by this, but that's more of a usability issue on your side and less of an SEO issue. Does the structured data from YouTube carry through embeds? For example, does the structured data need to be recreated on the page that embeds the video? So if you're using something like an iframe, then we can definitely understand a little bit about what's happening within the iframe and associate that with the page itself, which could be something like the title of the video, for example, on YouTube embed. But I would strongly recommend using normal video structured data on a page as well, because you don't want to rely on this vague Google might be able to figure it out thing, but rather you want to really clearly provide that structured data to Google so that Google can show your pages as proper video landing pages, because it has all of the information that it needs there. So that's something we definitely can carry some things over, but for optimal video implementation, for video optimization in search, I would use the normal video structured data. Why in the crawl stats report and search console, there are also very old URLs that are sometimes crawled for discovery and not for refresh? I don't know. I'd have to take a look at some of the examples to see a little bit more about what actually is happening there and chat with the team, but I wouldn't necessarily worry about this difference. It's something where I think splitting those parts out makes it easier to understand that Googlebot is actually refreshing a lot of your pages and that it's normal for it to access pages that have been the same for a longer period of time, but I wouldn't worry about individual URLs falling into one bucket or the other bucket. Will the ranking boost from core web vitals be based on the mobile or the desktop numbers? We announced that the core web vitals or rather the page experience ranking factor would apply to mobile and not to desktop, at least initially. I don't know what the long term plans are and my guess is at some point, we'll figure things out a little bit more fine grained, but at least the initial announcement that we made is based purely on the mobile side. And that's also where, for the most part, I think the harder barriers are, where users really see things a lot slower than on desktop, because on desktop, you tend to have a really powerful computer and you often have a wired connection. And on mobile, you have this much slimmed down processor with less capabilities and smaller screen and then a slow connection sometimes. And that's where it's really critical that pages load very fast. Search console data question. Data on the Search Console UI is slightly different than from what's pulled from the API. And the data in the UI looks more approximated. Is the data pulled through the API more accurate? So both of these sources are based on exact same databases internally at Google. It's not that we have one set of data for the API and one set of data for the UI, but rather it's the same data. It's available in different ways. And depending on how you query the API, you might see slightly different numbers. But essentially, it's exact same data. If a domain organizes its international sites and subfolders, would Google crawler have an issue with different international sections on a site using different page templates or navigation? Since a site navigation template consistency has been mentioned before as a factor in SEO, that's perfectly fine. So we do try to understand the templates of a page and to understand which parts of a page are the primary content and which parts are more boiler plates, like everything around it, the menus, the footer, the titles, things like that. But we can pick that up for different parts of a website in different ways. So it's not that the whole website has to have exactly the same template, most websites don't. The thing I would watch out for, especially since you mentioned international sites, is if you're using hreflang and you have very different infrastructure across the different language versions, then it makes it really hard to link those pages together with hreflang. It's not so much that Google would have trouble with it, but if you can't specify the hreflang yourself on those pages and you want Google to understand the connection between the language versions or the country versions, then that just makes it a little bit harder. But purely from an SEO point of view, if you can create proper hreflang, if these pages are normally crawlable and indexable, then I wouldn't worry about that. OK, wow, so many questions and so much more left. OK, but maybe I can take a break here, pause the recording. And if any of you want to stick around longer, you're welcome to do that as well. Thank you all for listening in, for watching, for asking so many questions. It's like, wow, so many hands are still up. So many questions still in. It feels like we could do these for hours and hours, but then I would probably, I don't know, fall into the ground or something afterwards, which would be unfortunate on a Friday evening. Cool, OK, let's take a break here. I'll pause the recording. And like I mentioned, if any of you want to stick around, feel free to do so. Otherwise, have a good weekend, and maybe see you in one of the next sessions. Thanks, John. Goodbye. Cheers, John. Bye.


and let's hope my stream deck plays nicely. There we go, lovely. So yes, as you heard from the intro, hello everybody. I am Jim Second, I'm a developer advocate at Cloud Communications Platform Vonage. So if you want to know a bit more about what we do at Vonage, we've got a sponsors room, so head to the sponsors room. Importantly, we've got a code that you can use to get some free credit if you want to test out our, if you want to test out our APIs, if you want to test out our voice APIs, SMS, WhatsApp messaging, things like that. We will have Cloud Communications Platform for that. And we have a more importantly for people, we have a raffle. So if you want to join the raffle, sign up for the service and you've got a chance to win some headphones, which is all very fancy and all very cool. Now, I was introduced obviously that PHP was mentioned a lot. I am the PHP developer advocate at Vonage, but that's not all I do. And the important thing is for anyone who thinks this is a PHP talk, it's not. And you'll see why it's quite cool. So yes, here are my, here are my, is my stuff, if you've got any feedback or you want to, or there's any, we run out of time for questions or something like that. I'm very active on Twitter. I've got a LinkedIn and like every good developer, I have a huge GitHub graveyard of unfinished side projects. And as mentioned before, I am the PHP advocate at Vonage. So let's get started. I'm just going to give an outline. I'm going to give an outline on what, this is how this came about. It's sort of a mini story at the start of it. And what came out about it and how I'm going to tell it. So first things first, hopefully something we can all agree on. Test the external APIs that your software relies on. It's hard, right? That's not that controversial. It's hard. Your software uses another API, right? You have no control over that API. You've got to test it. How do you do that? I found something. It's a library, found it. Tell you what, it's not even cutting edge. It's not even new. It's just it's been going on for, old tech it's been going around for ages. So I thought, okay, give it a gun, check it out. And the conclusion is, oh my goodness. What is wrong with us? Why is everybody not using this? Everybody should be using this. We've got it all wrong. Whatever you know, it's all wrong. It's all wrong. We use this. I'm being, of course, a little bit dramatic because I have a dramatic background but this is what it sort of looks like. So I'm going to talk about how problems come about when you have external API dependencies and what the library is that I found and what it does, when to use it, how to use it, should you use it? Because, you know, as always it depends. Right. I wonder if anybody in the audience knows what this is or this is point the right way. This is a beta max tape, a closed proprietary format introduced by Sony. It was technologically quite superior for its time and a very interesting fact for you. The last ever beta max tape was produced in March, 2016 which is ridiculous. That's how long they're actually being produced for. On the other hand, this is something that people might recognize more. Well, this is something that people over the age of 30 might recognize more. This is an open format. This is Fossasia, after all. An open format called VHS, which was designed by JVC and was adopted by Mitsubishi and Hitachi. This was technologically not as superior as the beta max format. It wasn't as good, but it was an open format which meant that it was adopted widely and it absolutely killed beta max. And there is, there's a story there, I think, behind things. So because, you know, I know what you're all thinking. You're all thinking, come on, Jim. Is this really relevant? I thought we were talking about APIs. What's going on? What's this? And the answer is, of course, yes. Why else would I be talking about it? Of course it's relevant. Oh, God. Oh, hard to please. Oh, look, and VHS came out first too. So that's an interesting fact that I didn't know about. Anyway, yes, it is relevant. I mean, sort of, sort of, you know, a bit, what I'm trying to say here is like, it's a tenuous link, but I've got to get your attention somehow, right? What I'm trying to say, what makes this relevant is this very important message, which is sometimes the most practical solution in software is the best one. Beta max was the correct option because it was technologically superior, but it wasn't the best one because it wasn't the most practical option, which leads me onto bug bears about software development I have. And this is the biggest one, first of all, which is this quote. Oh, don't muck what you don't own. Look, do you know what, when I hear this, when I hear this as like a staple in the software industry, don't muck what you don't own. I think of a film from 1998 called The Big Lebowski and it takes place in a car and the scene is wrong.  And it's so true though, isn't it? Don't muck what you don't own is like, it's not wrong, it's correct, but it doesn't make things easy, right? We have things hard and not being able to muck something that you actually rely on is like difficult. So, what I'm trying to say here is that we already have the tiptoe around external dependencies. This is, I come from the PHP land, but if we're starting to get to node in JavaScript, people who use those ecosystems know what NPM is like, right? You're downloading thousands and thousands of other people's code and libraries. This is why we need tooling. And given how difficult it is and we have to solve so many problems, it leads beyond to my second bugbear and this is a bit different because I have respect for, I have respect for don't muck what you don't own, but this, something that I hear all the time. We don't have time for testing. Who says this? Oh, we don't have time for testing. If someone says this, if a company says we don't have time to test our software, I think clowns, absolute clowns.  Let's look at why that quote comes about. Why do people say we don't have time for testing? I'll give you a real world example from something that I worked on maybe about three or four years ago. So imagine you have a thing. Let's say you're building something for Shopify. So it's a cloud-based platform. You have no control over it. You have access to all of its API. How do you build and extend off Shopify when you do it via its API? So I have something locally. So in this case, I've said Symphony Framework could be anything, could be Flask, it could be Django, it could be Express, I don't know, any kind of full-stack framework, right? And the way you communicate and extend off Shopify is you use the API. And then if you want to take states out of Shopify, you store the state locally and you sort of amalgamate to the two talking through the API. So how do I test this? How do I write this? How do I write my service and I want to test it? Okay, well, the industry norm seems to be, well, we need to separate out. If you're gonna test it, you can't talk directly to Shopify, right? Any more, don't mock what you don't own, right? So you're not getting control Shopify there, but you can't own it. So you need to ring fence the API and then I'm going to use PHP unit and PHP spec for sort of for mocking. So for anyone else, this is like Jest or it's like R unit for, sorry, R spec for Ruby. This is the testing run, right? So how do you mock the API responses? Well, what you seem to do is you create static fixtures as like JSON. You have like a whole load of fixtures in JSON files, right? And then that's what you're testing against. Okay, fine. So what happens when this happens in Shopify? Yay, API change. And then you've got your API change and it's so bad that it's in like WordArt from like 2001. So if the API changes, then what happens to the JSON? The JSON is now like totally, totally wrong because it's not the, like, if you haven't got an API change that has been documented and you didn't expect it, therefore your responses are wrong and therefore PHP unit goes, I don't know what's going on.  It's all wrong. It's all wrong. Just forget about it. And that ladies and gentlemen is why people say we don't have time for testing is situations like that. The talking of situations like that, I'm in that situation, right? I have exactly the same problem at Vonage. I'm responsible for the PHP SDK libraries. I if you want to talk to Vonage and you're a PHP developer, I maintain the open source library for it, right? So what happens is you have to talk to Vonage's APIs. How does it do that? Exactly the same situation. But being a center of excellence at Vonage Engineering, I'm not just going to say we don't have time for testing because that doesn't work. So you've got to have some sort of solution for it. And this is how the solution kind of came about. I work in a multi-language team. There's a Python advocate. There's a Ruby advocate. There's a Node advocate, et cetera, et cetera. So I was talking to the Ruby advocate and the Ruby advocate Carl goes, he says, oh, I've got a solution for you. Why don't you just use VCR?  But what? No, hold on. Stop, stop, stop. Go back. What do you mean use VCR to do the testing? He's like, yeah, it's in Ruby. It's called VCR. What it does is it records all of your APIs and then plays it back. And I'm like, okay. Yeah, but there's not gonna be a PHP one. And he goes like, eh, hold on a sec. Yeah, here it is. And just like that click, I was like, what's this? What is this magic? And I checked it out and I was like, oh my goodness. Why are we not doing this? So let's talk about what it does. What does it do? So imagine we have our brand new NICAM Matsui, digital VHS recorder, Matsui being a British company that tried to pretend to be Japanese because that's what it was like in the 90s. And you presumably want to try and set up your auto program record, which was something that seemingly never worked. And what you do is the API is what you're recording. So we pop in a cassette of our limited edition Jurassic Park, sorry, not Jurassic Park, sorry, our Vonage API. You plug it into the cassette, you run your unit tests, you press record, it records it, and then you take out the cassette and you put it into your API library of all of the things. And then when you want to run your unit tests, you pop the cassette back in, press play, and that's it. And what you've done is you've cut out the API. Okay, that's pretty cool. How does it do that? This is stuff to do with PHP, okay? So what it does is anything that goes over curl or if you're a masochist soap or the streammapper, it intersects it, right? But how does it do that, Jim? And the answer to that is, okay, look, please don't ask me how the author's got around Ruby's monkey patching to do this because it's probably voodoo leaves and chicken bones and things like that. The answer is technically under the hood. It's very complex and I don't know quite how it works. But how does it look? So it's got a base Singleton client. It's got a storage path. It's got a storage format, a mode, an on, off, and eject, right? And this is what it looks like in code. So you've got a base Singleton client in PHP. There it is, VCR class. If you use the configure method, it returns back a VCR configuration object and then you have all of your methods available on it. So in this case, you use set path and that's where your library goes. Storage format, you can choose when you record to store in JSON or you can choose XML or you could choose YAML. The mode is important. This is when you're like doing record or you're doing playback and it looks like that. So you've got set mode, new episodes, that means it will record everything. Or you can go to set mode to none. If you do that, that means that when you run the unit test, it will do it, it will put it into play.  Eject saves the cassette when you're completed, right? Very important that you have turned on and off because that's you're in control of what parts of your test suite you want to be recorded or tested. So that's how the code kind of looks, right? So a real-world example, how does it look with the testing? And this example is, yes, it is PHP but might look familiar to JavaScript developers. It uses what's called the PEST testing framework which is not quite the default testing framework for Laravel yet, but it will be. It's a testing runner that's designed on JavaScript's Jest framework, which is why the API kind of looks like this. So this is a live test. It will send an SMS to a live server at Vonage and then we expect the response count to be one, i.e. you've sent it and then we expect the status to be zero. That's a live test. You don't want to run that all the time because if you run that all the time, it will cost you money every time you do it and you don't want to do that in your CI and pipeline whenever you've got GitHub actions running every time, right? That's not what you want, but that is a live test. So what I did is I took a functionality specifically to do with PEST, right? You have a traits function or users function and this was built for things like, this was done for things like for unit tests when you need to do migrations, right? You want a fresh database for every single unit test you do. So what I did is I added those VCR methods into the traits. So now you can have like your set mode or your on and off wrapped around and that will now run as part of the test before every single test. So how does it look with VCR enabled? This is the same test, but now you can see you've got this switch VCR to true, now set VCR to new episodes. If you run this, this will record and then it will eject the tape and it will save it into the file system. This is how it looks. And as you can see, for those of you familiar with things like Insomnia and Postman, it looks very similar to that. It looks like an HTTP wire request, right? There's nothing sort of that mysterious about it. That's your recording and it says, here's everything I've recorded. It gives you all of the headers, it gives you everything, right? And when you want to play that back, we've put switch VCR to true, load in the cassette that we saved, set it to the play mode and now the live test exactly as it was before will no longer talk to Vonage. It will just play back what you've recorded.  So reasons why you should use it. Cassette libraries of API changes versus your external dependencies documentation. This is quite a cool kind of, quite a cool thing. It sort of goes a bit like this, right? So documentation needs to be up to date and it sounds ridiculous, but how many times have you coded with an external dependency on something and it's documentation is not up to date or something has been launched and it's not been documented yet, how it becomes a sort of a chicken and egg situation, right? You don't know, you don't know what, you don't know if you update the API, what we try at Vonage is we try and update the API at the same time, but sometimes that doesn't happen. Whereas if you use VCR, you have a single source of truth for your application and your developers. It takes out the kind of human documentation element. The documentation, yes, it needs very important at least to be there, but for what you're developing at speed, you actually have something that's more concrete. But what if your external dependency, what if they accidentally ship something or what happens if they break their semantic versioning that they have where they've accidentally had a backwards compatibility break? They could do that. There's nothing, you know, the problem is it's in their hands, whereas with VCR, it brings it back into your hands. The cassette libraries by saving document, like saving all of these cassettes as recordings, it moves the dependency from them to you. So that's why I would advocate for it as something that's very, very powerful. And similarly bug turnarounds and visibility. Now this is crazy, right? Here's an example, right? GitHub issue on your library or your project pops up and you go, okay, fine. It's because it's relying on a third-party API call and it's broken. Right, I'm gonna run the project locally and then I'm gonna tell it to record a new cassette. And now I'm gonna play it back with my test runner and bingo, the power that a developer can use for has a finding an API problem like that because the test suite has failed because you've updated what's going on with the external API. That's a fairly kind of powerful use case for using something like VCR. Another one, speed. There's a bomb on your boss, full credit to Keanu Reeves is acting. Do you remember before where we said we don't have time for testing, right? And I've just said, I tell you what, if you use VCR, speed becomes something that is in your hands. And here's an example of that. This is another thing which is like, here I'm going to show you the superpower of this library. So, build me the thing, Jamie. I've just chosen Symphony Framework or I could choose Laravel or I could choose Django or Rails. I don't know, whatever, build me the thing. Okay, here's the thing. The thing requires, it relies on an external vendor API as Facebook or Shopify. I don't know, some sort of big thing or Twitter, right? And that logo is for the open API spec. If anyone wants to know more about the open API spec, we're big into it at Bonnage Naturally, ask me about it because it's amazing. So it relies on this external API, right? So what you need to do is set up the vendor account and then you're just going to write the tests in your product and then hit record whilst it makes all the API records. So then you commit the tape into source or S3 or something like that. We'll get onto one of the downsides in a minute about storage, but you commit it and then go ship it. You've just created a piece of software that relies entirely on someone else's API. You've done it at speed with full test-driven development from using that library. And that to me is stumps. That's amazing. That kind of power really did, that's the reason why I just said, why aren't more people using this? And because I am a man that is approaching my forties, I like offline stuff, right? But it is important to notice this speed. It means that you don't have to, you don't have to make all those API calls all the time. You record them once, but it means you've also got potentially offline development. That's pretty powerful. Much better back in my day. Look at that Amiga, beautiful piece of kit. Old man yells at cloud, et cetera, et cetera. But as an advocate, it is my job to not just say you should use this thing. You also need to know about why you shouldn't use it because there's downsides to everything, right? This is a big one, external production vendors. You're relying on someone else, but what about the accounts and things like that? And maybe you can't set up a staging environment with someone else's thing. It might not be possible, which kind of brings in another aspect, security. You've got to think about how you organize your secrets and your environment variables. Real big thing here is third party data. You're making calls for external service. Can you set up fixtures and things like that? You've definitely got to make sure that you don't have any live data in there. Otherwise, the live data will make it into your local file system and record it in a cassette and you really don't want to be violating GDPR rules. That's in the UK, sorry, in the EU, but it's probably different out of the APAC. Maybe you can't set up a staging environment and also if you accidentally trigger something where you put record, it might cost you loads of money. What happens if there's 5,000, 10,000 tests and they're all making API calls? You're going to have to stage that and control it. And if you don't control it, someone accidentally runs the pipeline and then it makes like 10,000 API calls. That's going to cost you money. You've got to lock these things down. So it's something to think about. And another big one is in your library, you've got to organize your library, right? So you need some strategy about how you do it, about how you name it, about how, where you store it. And also your software might already have some CI pipelines and it does some fancy stuff, depending on git tags or something like that. It means that you have to work around a solution on how you integrate this into your software. But yeah, the top thing to take away from this that I think is absolutely amazing is, like I said, you might have thought this is a PHP talk. And yes, I'm a PHP developer, but it's not. This slide is kind of unique to FOS Asia because it's about free and open source software is this slide is the money shop, right? There's no sort of better way of putting it. It's not a PHP talk because I found implementations in, get ready for it, everything. There they all are, take a screenshot. If you want to use VCR, it doesn't matter what backend you use. There's one for Golang, there's one for Java, there's one for .NET Core, there's also one for C-Sharp, if you want to use C-Sharp in .NET. There's one for Node, there's equivalence of all of them. And that makes me realize, first of all, how powerful is software? And then secondly, I really don't understand why this is almost like not an industry norm, okay? So the conclusions, whilst I motored through this talk as quickly as possible. The conclusion to draw really is, first of all, make sure it fits your use case. As an engineer should say, it depends because it might just, this thing might not be applicable for everyone, right? And also we're all talking about your software relying on external APIs. Not everyone's software is going to be relying on external APIs, you know, something doesn't. But make sure, have a look at it first and make sure that it fits your use case of what you're doing. But in my case, it fits my use case for the libraries that I maintain. And so I'm now starting to refactor all of the open-source libraries that we have at Vonage, the ones I'm responsible for in order to use it. So that, big win, yay! But for that contribution for open-source ecosystems and how they work, it's very important that I sort of build on top of that. So what I decided to do is, I decided to create an integration to make sure that if you use Laravel and you use the test testing framework, I'm going to create like a plugin for it so to integrate it as part of, so make it part of your call Laravel installation. I don't know how long that will take, but it's definitely something that I think people are kind of asked for. So that's my very sort of brief introduction to PHP VCR. Thank you very much for having me. And hopefully in a second, the MC will pop up again. I was about to answer the questions in the chat, but Clarice, our community manager, is about to, I think, about the winner for our headphones. All right. Yeah, so I think, so we have one question here. I think it's not very clear to some people in the audience what exactly PHP VCR is. Could you summarize what it is? And like... If you have software that talks to other services, that uses other people's APIs, PHP VCR will allow you to record all of the responses from that API so that when you test your software, you don't have to make the calls anymore. You have it stored locally within your software. That's the really brief intro of what it is. Yeah, thank you very much. That makes a lot of sense. I have one myself. So you talked about offline, I'm personally a robotics guy, so we're dealing a lot with the different vendors of robots and they all have different APIs. Do you see this can be used in an environment like that? Like with like, because this seems to be like web oriented or at least the initial, what it comes from and what it's been mostly used, right? But do you see that if this can be used with APIs from robots or APIs from different kinds of software that are not like web frameworks or like web development stuff? Yeah, it could be used. I think it's kind of a difficult one. It's VCR by its nature because it's recording web calls. It's very much designed and aimed at about a full stack web development or web application development. But on the other hand, the thing is if you use something natively like React Native or Python's kind of like, or Python's compiler into sort of into Linux desktop apps and things like that. I mean, potentially you could still use it because in PHP is a web language only, right? So I mean, people try to port it locally to desktop development, but it doesn't work. But Python can be used for that, which means if you had a desktop application that did make external API calls still over the web, you could still use it within like a compiled app. I see. All right, yep. And then we have another one saying, is there any chance to see VCR web RTC replay ability if it's not there support already? Sorry, can you say that again? That VCR web RTC replay ability, if not supported yet already? I don't know the answer to be honest. I don't know, in terms of video, I don't know that much. I've only just started getting used to sort of web RTC. We've got libraries that use them natively, but if you have VCR, because VCR all it's doing is recording HTTP wire calls and their payloads. So it would probably be, if you're trying to record like web RTC interactions, you could do it if it was as long as it was using HTTP, but the only difference is that it would be probably a bit too expensive to use, like it'd be making like hundreds and hundreds of calls. But it could potentially be used. I see. Okay, I think that's all for questions. Maybe if there's some more, we can... The actual building on that question, sorry. I didn't realize that it actually relies on UDP under the hood. So the answer is no, but someone's probably ported it. Okay. All right, yeah. Yeah, so thank you very much. Very interesting talk, very interesting technology. And I very appreciate all the amazing images and the reference to the Big Lebowski. You're welcome. Thanks for having me, Abram. All right, thank you very much.