Beyond the SERP: Technical SEO Meets Web Performance
Anton, Jennifer Nixon, Brooke, Shardo Jensen, Dennis, and Tune discuss technical SEO and web performance. They cover website architecture, page speed, schema markup, redirects, and how to balance design with performance for better search rankings and user experience.
Hello, YouTube, how you doing? Today we are talking about technical SEO and we are joined by our friends Jennifer Nixon and Shadow Jensen. So before we dive into the main topic, I will introduce Brooke with the latest news about Changelog.
All right, hello everybody. As always, you can use this QR code to get our Changelog and you can subscribe to them so that you get them in your inbox. But actually, today I'm actually going to be talking about some upcoming events that we have going on. So first of all, our developers, After Dark, has been posting a lot of great new podcast episodes. So if you have not been listening to those, please make sure that you go and subscribe to them. This is hosted by our very own Dennis Edson, AJ Laporte, and his brother, Nick Laporte. And the latest episode actually features S.J. morris, who a lot of you all know who is our community manager. So you can go and watch that latest episode on the Devs After Dark podcast website as well as on our YouTube. You can subscribe on Spotify, Apple Podcasts, wherever you listen to your podcasts. So that is just a call out there. They're super fun episodes. I love listening to them while I'm getting other stuff done. Next up, our inbound call for speakers is about to close, y'.
All.
So Inbound, if you don't know, is our annual conference on marketing, sales, service, AI and more and more. And this year it will be in San Francisco at the beginning of September. So the call for speakers is currently open and will close next week on February 19th. So get your stuff in. And all applicants can now submit up to two applications. So if you're interested in that, go ahead and scan the QR code. And I look forward to seeing some of you all on the inbound stage this year. And, oh, we got a second one by inbound. Sorry. And last but not least, the HubSpot Eco Mentorship Program will open soon. And I know some of you all in the chat were part of our beta developer mentorship program last year, and so now this year, we are expanding it. So this mentorship program will run for nine months and applications will open on February. So when the inbound applications close, the ecosystem mentorship applications will open. So you got lots of applications to fill out, y'.
All.
And this one will give you the ability to both apply to be a mentor or a mentee. So if you are new to the HubSpot developer ecosystem, we welcome you as a mentee. And if you have been in our ecosystem for a while and you want to share all of the good stuff that you know about HubSpot developer stuff with new people, make sure to apply to be a mentor. And actually that is a great segue because next we have Jennifer Nixon coming on stage and. And she was actually one of the inaugural mentors for our program last year.
Hey, Brooke. Thanks. All right, everybody. So today we're here to talk about technical SEO. But what is it exactly? Hey, Nick. So anybody, feel free to drop in the chat your thoughts on technical SEO. How do you define it? What is it? You know, most marketers that I talk to, they equate technical SEO to sitemaps, robots, text and page speed. Now, hopefully you're all familiar with core web vitals, LCP largest contentful paint, INP interaction to next paint and CLS cumulative layout shift. If not, I'll drop the link from our last core web vital 101 event in the chat and you can check out the recording some other time. Oh, it didn't Dennis. It failed to post, so I don't know what I did. I'll give Dennis the link and maybe he can figure out how to share it. So, yeah, Nick, good point. Delaying scripts, CSS files for load. So, yeah, so today we are going to go beyond core web vitals, though we talked a lot about that. Page speed is just one part and so many people focus in on page speed and miss a lot of the other technical SEO. So at the most basic level, technical SEO is, is about optimizing your website's architecture to improve organic rankings. And we all know why organic rankings are important. The SERPs are changing, right? AI is changing everything. The way that it looks, the way that it functions. But there are still so many ways that you can optimize your website to rank organically. So, trick question. How many H1 tags should you have on a page? Anybody? Any guesses? H1 tags? Who thinks there should just be one H1 tag? And how many people think, nah, you can just have as many as you want. Oh, Brooke, one of all this. I'm. I'm shocked some people are still saying one. Yeah. So reality Google, from the mouth of Google themselves. You can have as many H1 tags as you want. The key is not that you only have one H1. It is that you follow a hierarchy on your page. So you're not limited to one, but your page headings need to have a hierarchy. Don't go H1, H2, H1, H3, H blah, you know, don't do that. Follow a hierarchy, H1, H2, H3 H4, H4, go back to H3, go to an H4, go back to an H2, then go up to an H1. So follow a hierarchy. You can have more than one. Now, a huge mistake that I see, especially with HubSpot websites, is people use the headings for styling. So they're like, oh, but I want a really big heading in the middle of my page. So it needs to be an H1. But you can tag something in H1 and style or tag something in H2 and style it to look like an H1. So styling shouldn't dictate the hierarchy on your page. And you really need to have a clear hierarchy. So headings are not just hierarchy, how it's styled, but how it's organized. And that's so key to how bots, like search bots, Google bots, interpret your site AI. This is exactly like what they're looking for. If you don't have the right headings, AI is going to be all confused about what's important and what's not important. Yeah, so sorry, I'm like doing my best to keep my eye on the chat. I love just seeing everybody's comments. So Nick, thank you so much for supporting the thoughts that I have. Hierarchy, yes. It. He's saying that it's the most important. So Google has context to the page content. That is it. That's a simpler way of saying it than I just rambled on, but love it. Okay, and then there's schema markup. So schema markup. You may have maybe you've searched for a recipe. I love this one. So I search for recipes all the time. Generally it drives me nuts that the same website show up at the top and I'll like go to page three to find like that hidden, top secret grandma's recipe for something. But if you have ever searched a recipe, there's a section at the top that's actually called recipes and it has the recipe title, it has a brief description and it has a rating. So the way that's happening, like how does Google know your site or that page has a recipe and how does it know to show it from. For those keywords, the trick is schema. So schema is what tells Google the type of content that is on your page. And yes, Anton, I am gonna, I'm gonna interrupt myself because now, Anton, I got distracted by the chat. I have my D hug shirt on everybody. So yes, it's official and I've got Hobbs in the background here joining me. Sorry if you guys keep seeing him over my shoulder. All right, sorry, tangent here. Okay, back to it. So that's schema, right? So recipes, recipes, news articles, your product rankings, products. Products are a schema and a lot of people will say like hey, why are my products not showing up when I search, I search the exact name and it's not showing up at the top, you know, in those Google snippets. Those are all driven by schema. And schema is just one of the many things that Shardo is going to dive in today. So I am going to hand it here. I'm going to stop rambling on and diverging into tangents with the chat and I'm going to pass it over to Shardo and he's going to share with us a very awesome demo on a lot of this. Hopefully I've covered some of it. So you guys know what we're.
You did going a bunch. Hi guys. Hello everyone. This is my first webinar in, in like two years or something. So I'm a little bit nervous but I hope it will get well. So yeah, we're going to talk about website speed and structure because that's something I like, I like a little bit too much a little bit often. How about me? So you guys know who I am? I full bear my website in 2002 for the old guys and girls among us that was in the time front page. When we work in front page with frame sets and building website with tables and slicing designs all together making websites that was a whole lot of fun. But that was a long long time ago. I have a wide interest in websites. I am not an expert in any field. I mainly like the front end of the development so more the HTML CSS stuff and I like the other technic co stuff. I'm working with upstart since 2020. I used to work at Fed Digital, that's now Bright Digital, the company turn works at and for now I'm working at Ixi, our wall decoration company selling wall art. So. Oh, just a little bit too much. So I want to make a statement just to start off I really think and research shows that quick websites make more money. My notes are gone again. Great. All right, so if you do a little bit research, every research will tell you that a quick website makes more money. And why does it do that? Because users are lazy, they are spoiled and they are bored quickly. They want instant feedback, they want interact on interactions. They want instant feedback and or a visible change. If you have a navigation or if you do navigate you don't want to Wait. These days we have a three second TikTok mindset. We can wait any, any bit longer than three seconds or we divert our mind. So we need a quick website to keep them on their feet. And next to that I really think that if you have a quick website, you have a structure website just like Jennifer just mentioned. Search engines will like you. And why do search engine like you? Well, for me it's very easy to to say this because I do think that if you have a small and quick website, search engine have to fetch less bytes to understand your website. Less, less time fetching, the information is more clear and therefore every bit of the search engine just screams. They don't have to pay a lot of money to rank you to understand you because your information connections to files and there is hierarchy between the files. They are loaded in a browser and it's on a user device. So we're a little bit in luck. If you have a website in HubSpot servers are managed by HubSpot connections need to be managed by developers fast by developers, hierarchy by developers and a browser and device. Well, it's a little bit of a fight between developers and users. So let's get into loading of those files. Well, loading of those files are important so you need to start off with the basics. What are you doing or what are you loading on a HubSpot website? So my first things I always do is turn everything on off. I'm sorry, Turn everything on off and have a look at what happens to the website. For example, if you disable the hip to chat and the marketing does not use it, will it be a little bit faster or not? If you remove some fonts that you can't locate or you can't see what's happening with fonts, turn it off and see and see if something happens on the screen for there are a few points that you can try to turn off comments, turn off social sharing, disable some tracking if you have no clue what's happening and it probably brings you to a certain point that you can no longer turn files off or remove files or anything and you have like a basic base fold website where you can start off with, with optimizing anything else. So if you have, if you are talking about files and you have files that you cannot remove, it's important that you load them on the same domain as your website itself. So in this example on the left you see two lines on line 7 and 8 where the fonts are loaded from Google API and we have a gquery bit of Code or next to Gquery not being necessary most of the times you see a green, purple and an orange bar that are unnecessary because this means that you connect it to a new domain. On screenshot on the right you will see that if I remove the files, the website is quicker. You can see that it's quicker is that it has a green line on the left one on about 2.1 seconds and on the right on 1.4. And it's simply because they no longer have to connect to a different website. It blocks the rendering of the page. So that's the important part of having files on the same origin. But you are in luck. We're building websites in HubSpot so you can do that with the default file hosting domain. If you set it to your own website, every file that is uploaded within HubSpot will be on your same domain from the same region. So you have that one fixed already. So some other easiest fixes that you can do yourself is hold GPO yourself if you really need it or please remove it. It's even better if you have Google Fonts. Often if you self host those fonts, you can download them from from Google Fonts and you make it a little bit faster. If you use the Google the font selection and HubSpot team, you're in luck. We also load them automatically from the same domain. Some import rules for CSS please remove them or make them in line and images upload them all on HubSpot. So it's pretty easy fix altogether. And along with the resize image handler from HubSpot itself within Hubble you can make it even better and make sure that the files are a little bit small. I'll come back to that one a little bit later. So if you have all the files on the same domain now we are up for priorities. So you need to make sure that all files have the right priority. So how the browser works, it reads from top to bottom a little bit different, but let's say top to bottom and every file is encounter reevaluates the page and sees if they have to make changes or what it has to do. And every file that accounts have a different priority. So I have a little explanation. I will share the link later on. But if you have a background image within CSS the browser moves down from the headphone and see the CSS and CSS is a render blocking file. So nothing happens on screen, nothing visual changes. So the page stops rendering. It will encounter the image as a background image for example. Well that's a Pointer, first pointer, you load that one in and after loading the file that takes a little bit, it keeps going down and after a little more or the page is loaded and you have something on your screen. But if you move the image to the header within a header, it's even quicker detected even quicker. And it no longer depends on the css. So that's a little bit of a win win for you. So what do you give priority? Well, in my ads it's pretty simple. You have a big image on a homepage. That homepage image is probably your larger contentful paint. You have that of fetch priority high. So on the right I have a fetch priority high line on line seven that shows how to do that. Same with custom fonts. Fonts needs to load quickly because if it's not an image, your LCP is probably a piece of font of a piece of content that probably has a custom font. So make sure that loads pretty quick. In hata as well. I got one on the second snipper, I do it with a preload. So to make sure that the first thing encountered by the browser is the image or is the font. If we go back to images, there's really no excuse to making images quick. We go back to fetch priority large contentful paint. You put that one on high if it's an important image. If it's not an imported image or it's below the viewport, don't mention it or put it on low. Otherwise for images itself, if it's above the fold, make sure it's loading eager or auto. But if it's below the fold below the viewport, put it on lazy simple. If the browser detects your image but it's no longer needed because there's no not yet in the viewport will not be loaded as quickly, it has a lower priority and therefore other things that might have more priority because they are in viewport are encountered as quicker and loaded quicker or discovered quicker. I need to say discovered because it's not really loaded. The same goes with an image source. If you set a good image source and you have an image on mobile, you can load a smaller image than on a big desktop screen. So in this case you can determine what is loading on what type of screen. So we go to redirects. Redirects are also a simple way to gain speed on your website. So a standard redirect. I made a screenshot from my own website for my company, that's a simple redirect from page A to page B. But if you have multiple Redirects. So I encountered an issue at our website. You see that on line two, that's an, an additional redirect, a second one. But that's 366 milliseconds of waiting of doing nothing for the browser before it goes to the next page. So the user also has to wait 366 milliseconds before it sees anything. And that's just a way. So you need to fix those redirects. And the redirects are fixed by simply linking the first URL to the last one in line so it no longer changed. And also the temporary URLs so the second domain to third domain, how to find all those redirects. I really love the tool Screaming Frog. It's one of our favorite tools for technical SEO and all sorts of other things. But you can run a screen for Screaming Frog website. It scans your whole website with all common issues and all URLs. It's really, really powerful. Also really heavy. So make sure you have a decent, decent laptop or computer. And in the overview tab you can see all the redirects and you can also see all the redirect change. So you can click on one and see what is happening. So if you have all the structured data, if you have all the websites feed in place, we can talk about structured data. Because structured data is a really powerful tool. So what is structured data? Well, structured data is a way to tell the page what is happening on the page. So what is your content about? And there's lots of ways you can structure the data. So Jennifer already told me you can have a H1 and H2, a paragraph or anything that's structuring your data, your content. Same goes for Search engine in your browser while it's in your title fields in your tab. And Google or Search Engine understands what the title is of your page. With Microdata you have is a more extensive way of HTML than search engine. What is what within the content, but it's not used for styling and which is now do you have heavily structured information about your website? And the last one I really want to talk about today. So then don't let search engineers guess what is what. Give them a little bit of help with structured data. So with structured data, you can tell a search engine what is the price of a product or what is the organization of a blog of an article, or what are the amounts of product in stock. And you might ask, hey, if that's on your website and it says stocks five, for example, that's fine. We can understand because we are human. What if we tell if someone else goes along? If a surgeon goes along and sees a number five, it has no clue, no reference to that stock. And with structured data you can simply say, hey, it's a stock of the product. So that's a really clear way for search engine to understand, for Chrome to understand what your page is about. And there are many, many ways to do this, so I can show you a bunch later on. So the benefits of structured data is it gives you search engine understanding of you and your page. It makes a better understanding of your entity because you're telling which piece of content written about by who or by which organization and all that kind of stuff you link to social media. So you build up a whole entity of yourself online. And also the benefits, and that's a little bit of why I'm here is that it also provides rich snippets so you have a better serp, a better look of feel, high positions and ctr. So for example, I made a quick demo for my own these are five stars in Google. There's really a page of me in Google. If you, if you look it up and I have the review snippet in here, you see five stars as five stars in my search engine range page. And this is simply the power of this snippet on the right. I just tell Google that I have 10 reviews with an average rating of 5 and now I have a rich snippet in Google that really looks great. And besides the competitors, I'm the only one with a review. So if you want to stand out in your syrup, these are the things you can do. I must say this is just a lie because nobody has ever reviewed my work and therefore so please don't report me. But this is the power. You can do this within a couple of hours and every page besides your homepage have five stars in Google. The same goes for an example for the product. Anton will show a little bit more. Thanks of the courtesy of Bright Dacio for providing the snippet on the left. This is a way how you make in Hubble within HubSpot product schema module with all the types of field that produce a schema somewhat like the snippet on the right and of the screenshot. And you can see with all those bits of structured data you could provide the review score, you could provide the stock price, you could provide the price of the product. And if you don't do this it won't appear within Google and the serpent. So this is really interesting well, Jen will also talk about the recite receipt. This is one of the examples how it could look like if you want to make some homemade pasta. The creator of this article is 101 cookbooks. You see the ingredients, the times it takes to make the pasta. This is the power of rich snippets and this is the power of of structured data and I really advise you to follow along. I broke down my my sheet on this one. What I have on for the for the online car sale. Even for these types of pages. The creator of this article is 101 cookbooks. You see the ingredients, the times it takes to make the pasta. This is the power of rich snippets and this is the power of structured data. And I really advise you to follow along. I broke down my sheet on this one. What I have on for the online car sale. Even for these types of pages, there is schema. There's schema for everything and even for the trunk size of your cardia schema. So it's really a huge thing online. Oh, I'm not moving forward. So if you want to know all the types of rich snippets and what the code necessary is to gain those rich snippets to go to one of these links, I will provide slide deck later on. But it's really interesting to have a look@schema.org and what is so possible. And if you really want to go extremely, extremely heavy on the structured data, you can even link towards different websites to say, hey, this is the brand of that website, of that article or that product, get all the information of that specific URL and in this way you don't have, you still keep one source of truth and you don't always have to write it out by yourself. And there are many, many more ways like this that are really, really interesting for everyone. And as a bonus, if you really don't like writing JSON, LD what you are into, AI, GPT and all that kind of stuff, you can run with Screaming Frog, a script that provides with AI your own schema for every single page so you don't have to do it yourself. It is possible. There are lots of other tooling, but this one is just released on. Well, it was today, the article came up today, so I put it into the slides. But that's an interesting point. So with that small information I really want to get to the round table because I know there are really interesting questions from Dennis. I do want to say that I think the structured data and php issues are developers issues and I do think that PageSpeed issues must be fixed for free. Yes, I honestly do think that. And the last one is that structured data of any kind should be built by default because we all know it exists. So it's no reason to leave it out in any certain of. In any situations. I want to thank you and I want to give it over to Anton because he has a great demo of the product schema, if I'm right.
Wow, this was something, right? So thanks Shadow. I mean, as always, amazing content and I have prepared a few code demos that we already talked about and I've seen also in the chat right now. So first of all, this code basically belongs to Sharda and I've made a few updates here and there, but mostly it's Shadow's tool. He did an amazing job for creating a module that is generating a schema, right? And the whole thing is putting or is getting put to the header or to the head tag. So I mean there are a lot of lines of code because you have product name, product description, is it a brand? Yes. No, because if you turn something on then this whole thing appears. You can type in again product name description, you can upload an image.
Add.
The description for the image, sku, MPN and so on. Then is it a simple offer, is it an aggregated offer or is it a variant offer? So basically configuration module for your schema, right? And if you are using it in production, then it's also possible to just put in data automatically from the page. And how this can be done or can look is something that I've done many years ago with my OG details module. So it looks where is it? There we go. So basically this OG module, the OG information is for social networks. So also something worth considering when optimizing SEO.
And.
This module here is built quite simple I would say. So it uses either the module input or automatically grabs the page meter or meta description featured image if there is one, if not you can set one and so on. Right? So the schema header is very, very similar to that, but with different information and a lot of information, so to say. Again, we have. Let's just stay with a simple offer here. When we enable that we have the SKU this number, then the offer name, you can set a price like nine, right? And this is something that I've added today. You can set the currency and it will automatically add the price currency and convert the number. And if you are looking at, if it's implemented in a page that is for instance in English, then it will convert the price to the US version I would say if it's on a German page, then it will transform the price to the German writing style. You have price valid until like a date conditions. Is it in stock? Yes. No, you have seller information, so quite a lot of stuff. And yeah, the last thing that I want to show is preloading images and it was mentioned in the chat by Nick and others and also Jenny made the introduction to this in the beginning. So what you want to do is you want to preload your above the fold image and to do this it's quite simple I would say. So the only thing that you really need are basically those three lines of code. Is it readable? I don't know. Let me zoom in a bit. Okay, now it's getting really big. Yeah. So basically require head. So this will be put into the head tag automatically. Then preload image and then in this case how I've set this module up, HERO config, background image and then just the URL. Also what this module has is you can set the fetch priority which Shadow mentioned. And since I've read that in the chat, let me zoom out a bit. So what you want to do is hierarchy for the headlines, right? And for instance this headline, since it's above the fold, it should be a headline one or H1 but maybe you would like to have it in a different style. So for instance, let's say an H4. Right. So we have an headline tag H1. So Google will see it as an H1 but the user or the human I would say will see it styled as an H4. Right. Super simple. Basically what you have to do is yeah like put in a choice field with the class. So if I open this, it will take the H1 as a value and then put it in here so you can. Where is it? There we go. So basically it's utilizing all the classes here. And this is also something that I would always recommend to add to all of your headline elements. So yeah, and now I think we are ready for the round table.
Let's freaking round table this. Let me get everybody up here real quickly. I'm going to remove your screen. Yeah, Jennifer, get up here too. This is beautiful. But I want to start first of all about the structured data. Sharda, when you were demoing that, it looks static. I'm assuming there are better ways to actually input the values when you are creating that module. Correct. Are you pulling from other sources? How does that work?
What you can do is or create a static. So on every page you have to fill all the information. You can grab it from HubDB or anything or a custom. Oh, what is it called? HubSpot. Custom objects or even sources outside of HubSpot. If you have a server somewhere running with a database you could put it in. So it's really brought in how you can fill information. And that most often is also the hardest part of structured data, if you ask me.
Yeah, I'm curious know how I mean this is obviously very important. How do you talk with the marketing team to make sure that you know, we are. You're getting the right things in there and it's easy for them to deal with. Tune. I'll ask you that one.
Yeah, great question. It really depends on the kind of structured data that we're working with. If you're looking at like a breadcrumb structured data that is mostly something that we make manageable from a module. But we also for example have a job posting site built on top of HubSpot and that is pulling data from HubDB and that is all built dynamically without having the marketeer or the manager of the website having to input additional data. So it depends on the use case.
Yeah, for sure. I'm going to go through a few questions. We got in the queue here. Before I get to these some hot takes I want to see everyone explode and discuss. Okay, starting at the top from Steve. I notice you have require underscore head. Is that recommended for this schema I have been loading at the bottom of the page. Sharda was from your. From your slides, I believe. Can you for that?
It's also provided in the hat and most often people recommend putting it in a hat but it also works down below. That's all I want to say about it.
Yeah, yeah, yeah, for sure. All right. Nick, who has a very interesting username of I'm so trash. Someone explained priority for redirects in HubSpot. This was already mentioned. I missed it. So would you mind just real quickly covering again the. The redirect priorities that you discussed briefly?
The redirect priorities? You mean the redirect chain and all that kind of stuff?
Yeah, I would say just. Just very quickly just say go over that again like you don't want one redirect to another redirect to another redirect.
Yeah, that's fine. We. The issue is often that you have multiple redirects in a row. So you go from domain A to domain not domain page A to page B to page C to page D. And in this case if I have those four Pages in a row, page B and C are redundant. You don't have to fisten them anymore, but in the chain you will visit them only for a split second. So if you remove those from a chain, from the chain and you move A to D, B to D, C to D, you no longer have to load those two files in between or two pages in between, you will say 200, 500 milliseconds down the line. It's quite a bit on the website and what Jennifer talked about. It's quite a bit on a core web vital scale.
Yeah, I think part of the question too, it looks like Nick is asking, is priority so you can number your redirects. So if anybody has ever managed a large volume of redirects, how do you decide what the priority is? And I think it's really important, you know, Nick says one or a hundred thousand. Well, the way that I always look at redirects is like any redirect of a homepage or the root domain, like your HTTP to HTTPs, that sort of thing needs to be like 1, 2, 3 and then from there you can go in blocks. Like if you're going to migrate a blog from another CMS to HubSpot, start at, you know, 50,000 and use 50,000, 50,001 and number up from there. And that just keeps them organized in terms of like priority. But if you have something like a pricing page and you need to change the URL, or you have pricing pages in, you know, multiple languages or adding redirects to them, then you want to start those in like the tens or the fifties. So I look at it like, okay, what are the total volume of pages? If I have a 10 page website, I'm going to start my redirects at, you know, 1 50, 100, 200, 300, and I'm going to group them pretty small. If I've got a massive website though, I'm grouping them in the 20,000, 30,000, 50,000 and kind of have that spreadsheet so that you know, all the team pages are always going to be in like the 30,000. And I know like for that site that I can find all of those redirects. And then if you need to add another one in your audit, you can go in and you can add, you know, that re number that priority. I was gonna say I like to use priority as like I have looked at this redirect and I know it's where it's supposed to be because like when you go from one audit to the next. So like if you're in Q1 and Q2 and 2000 redirects have been added. They're just automatically numbered starting at a million. So you can just jump to those in your spreadsheet and say, like, okay, where do these fit in? You can go to that section. You can filter by the prior priority and say, oh, these are in my 30,000. And look, I've already got. Now I, I found that chain. So there are ways to do it. If you don't have Screaming Frog, if you don't have these technical tools, you can find those redirect A to B to C happening without having to go through like those tools.
But Jennifer, this was my actual next question and I wanted to send it to you because this audit, what, however frequency you do it, it can be pretty freaking overwhelming. Right? How, how do you actually fully manage this? What is your process, if you don't mind giving some insights?
Yeah, I think it, for me, it depends on the volume of the site. You know, I have small sites with 50 pages. They might do a redirect once a year or twice a year. I just, that's an annual thing, right? You're going to go in and on the same day of the same month of, you know, every year, you're going to go in and you're going to check and make sure that those audits are in a good spot. You have thousand pages on your website. You probably need to do it quarterly. It really depends on if you're unpublishing content. Adding new content, totally fine all the time. But if you're unpublishing stuff, if you have promotions or campaigns running where you're unpublishing landing pages, where you're unpublishing blogs or you're unpublishing different assets, that's where you really want to look. And then just pick a cadence, you know, monthly, quarterly, annually, depending on volume. Have some that are actually like bi weekly because they just publish so many. And, and once you have a process, though, like once you have a process for auditing, that's something you can easily pass on directly to your client team or whoever is managing that site. You don't have to, you know, go in and have this huge undertaking to just focus on redirects as they're adding them, they should know like, hey, this is a new one and here's where I need to add it and here's what I need to do priority or here's how I configure it. Because the worst thing to do is just like blindly add redirects Right. And not own them.
Do you, do you work with temporary redirects quite a bit or is it usually, you know, just permanent?
Yeah, temporary redirects for me are great. If you're going to like, maybe you have like a promotion that you kind of put live and you need to pull it down because you're not really ready to push it out or you change dates on an event or something like that, you can use those temporary redirects. It just tells Google that there was content there and stop looking for right now. But don't take it out of the index yet because I'm going to put something back on this page. If you have something that goes like severely out of date and you need to update it, but you have to bring it down in order to get those updates, you just can't leave it up. Legal says nah, we just, you know, take that down, put the temporary redirect up, let Google know that there's content coming back for it. But it's rare. I think it's pretty rare. I don't know. Shardo, do you have temporary redirects a lot? No, I was gonna say it's pretty rare.
Yeah, yeah, yeah.
I, I, I often just put, put in a simple redirect and I still stand by my case. And if you remove a page on purpose and has not that much redirect value to it or rank to it, just leave the 404. It's removed, it's not there, it's fine.
Interesting. I'm moving on and this is not a question, but I'm going to use it because I had this question already set free to talk about. I just blame the designer if the website is slow, which is classic Carter, never taking blame. But this is a legitimate question. When you get designs that are really beautiful, right? I mean like just amazing freaking designs. But you know, building it is going to cause a lot of, a lot of bloat, a lot of, you know, speed issues. How do you handle this? How do you mitigate these issues? I want to ask Tune. No, no. You know what, Anton, Anton, you, you are both a designer and a developer. So I'm curious to know how you do deal with this.
I would say the most important rule for a real designer is function over form, right? So you can go real or you can be very creative and design whatever you want because basically you're starting with a blank page. But I think it's a huge benefit if you as a designer has, have basic knowledge of development because this helps you understand hey, how should I design something without getting into the bloat world? I would say, right? So of course you can say, hey, I want animations everywhere, like in the intro, right? So everything is blinking and fading in, fading out, whatever. But is it necessary? Right, right. Is it important to have. If it's not important, cut it. Got it from the design, right? Yeah.
Tune. I'm gonna ask you the same thing real quickly. Let's say I am the. The owner of the site. The designer has decided to put 37 sliders on this page. I want them all, buddy. I want them all. All right, so you do it.
Do you.
Are you going to come back later on with some sort of like, performance review? Show me, like what's happening with it. How do you handle if it's already.
Been implemented, if it is already implemented. So if we get a design with a lot of sliders, we're going to develop that with performance in mind, right? So we're going to make sure that the images are resized, we're going to make sure that they are loaded in the correct way like Shardo described. So it really depends. And I honestly think that HubSpot is giving us a lot of tools, both on a development side, but also on an editor side, to make sure that performance is always in mind when creating and editing the website.
Right.
So it just starts with building it with performance in mind. And even then we still have to double check how clients are editing, adding images, if they are using the right file formats, if. If we can improve that somehow. But a lot of that can also be automated. So there is a lot we can do as a developer from preventing both designers and marketeers of messing with the performance.
So this brings me dovetails nicely into one of Sharado's hot takes is that it's the developer's responsibility for site performance. Do you think that is correct? I mean, if I am the person who wanted this site and I want it this way, is it still on you? What do you think?
It's a hot take. And I also think that it should all be in balance. Right. So having a really fancy design that is also technical performance is something that you have to balance. And sometimes you have to make choices where, you know, okay, it's going to negative, negatively impact the performance somehow. But that can be okay because besides performance, UX itself is an important, pretty important subject.
Right?
But to answer the question, it really depends. If we're building a website, it should be built with performance in mind. If we mess something up and it isn't performant, then yes, I think we should fix it because we want to deliver a certain quality when we're building a website. However, things change as well, right? So Google is going to implement new best practices, new changes are going to happen. We're going to have to keep AI in mind now and those kind of updates can be an upgrade. I think that could be paid for.
Shardo was, he was pretty adamant that there's no depends to this. This is, this is like all on the developer. Are you, are you gonna defend this? Shardo, do you feel like this is 100 on you?
Well, I made sure I didn't, I didn't say that it's.
You can't take anything back. Right now we have a slide proving that's on you.
I, I still think that the developers responsible that website is proving, I didn't say that it has to meet the core web virus guidelines because indeed if you have a huge, huge slider on top, it's an UX problem, a marketing problem. They didn't do the research, so they have to be eliminated by it all by itself. But if you have a really nice website that does require more power, more time, too low to make things look good, you still can have a performance website, but you will not meet the equal Web five. And that's fine. But it cannot be waiting for five seconds when it can be done in two because you're lazy.
Gotcha. And Jennifer, we have two minutes remaining and I want to give you the last word because when we did this dry run, your eyes did something pretty special when sh had this hot take. Can you. How do you feel about this?
Yeah, I don't think I can recreate my eyes popping out of my head. I think that's where scope comes in. You need to have a very clear scope. What you're going to promise for performance. Most of you guys are devs here, sitting here saying, well, we're going to code a performant website. But a lot of times the people selling the website don't really understand that as a developer, you want to make it as performant as possible. But if the scope doesn't allow it, then your hands are kind of tied. And so you have to have a very clear line of communication of what you're promising in terms of performance. And that should just anytime you're doing a website, performance should be a line item in your scope. And then you hold yourself to that.
Brilliant.
It's perfect. All right, I'm going to end it there, folks. Please come next time. What is it the 27th? I think it is. So we have our next developer hug, which is going to be on the elevate theme and CMS react. We've got some opinions on that already between the, the hug leaders, so we'll, we'll have a heated conversation in that area as well. But everyone, have a great rest of your week. Have a great weekend. Do you have fun and be safe out there later on, y'.
All.
Thank you, but.
