Truelogic Episode 33 Recap: SEO is Not Your Web Developer
Are you looking for a way to get collaboration, understanding, and success in digital marketing? Do you feel like you’re not getting the results you want, and you’re not sure what to do? If so, this episode is for you. Today, you will learn why your web developer is not your SEO and why they should work together in harmony to produce the best results for your website.
Berns San Juan: Let’s talk about web developers. Actually, to be specific, let’s talk about how SEOs are not your web developers and they are not your IT people. Understanding the ways web developers and SEOs collaborate can help you understand but I think in a lot of conversations, people… because SEOs work on a website and IT people work on a website, and web developers tend to work on the website, it is understandable that brands can’t differentiate between the work that one does versus the others, right?
So how do they stack up against each other? Where do they collaborate? Where does one line end and where does another begin? I think understanding this is crucial to managing any website and to your digital marketing approach, and the success of your website isn’t really about your web developer versus your SEO, it’s about your web developers being successfully utilized by the people that do your SEO and to a degree even your IT team, and then working together in harmony to produce the best results for you.
In today’s Truelogic DX podcast, we’re going to go over some of the most essential things that digital-age business owners and marketers need to know about SEO versus web development and why your web developer is not your SEO. Let’s get started.
Difference between IT and SEO
Berns San Juan: When you’re building a website, let’s start first with IT teams because, in a lot of brands that we work with, the custodian of the website is IT. But I think, to differentiate, IT is an infrastructure provider. So when you need hosting, let’s say even to purchase a domain name, although your web developer should be able to do this. Setting up your hosting, a staging environment is just a sandbox where a playing website can be built. It’s not meant for the public to consume. It’s not meant for the public to use this as a testing environment. It’s a sandbox for the website. That’s IT. Getting your encryption codes, and your SSL certificate. Hardening your website, the security of your website. That’s IT.
Security of your website is not even web dev. Once your website is infected with malware, there are code injections, then web dev steps in. But the hardening of the security of your website, to begin with, that’s not a web dev function, that’s not an SEO function, that’s an IT function. The web devs audit that, and the SEOs audit that, but it’s not, they don’t build that out from the get-go. So it begins with IT.
Once a staging environment and a live environment have been built. So I’ll repeat, right? Like once a sandbox has been built and a live environment has been built, the work progresses to the web developer. And the web developer does a couple of things, or at least the web dev team ‘cause it could be a full web design team, right?
Their job is to build out the designs of the website, and what it would look like if it were viewed from a desktop. What it would look like if it were viewed from a mobile? To convert that design into the requisite HTML and CSS elements. That’s part of the job. And then to code the site, like to start building the code that will express itself in the website that you see and interact with. So these are what web devs do.
Essentially, the web developer builds a website that functions, but the keyword and the primary priority of the web developer is functionality. Functionality is not the primary concern of SEO. The primary concern of SEO is rankability. It’s crawlability, it’s rankability to a degree. If you’ve got a really good SEO, it’s messaging like are you satisfying a search motivation that the user did?
So once the web developer has built the website, implemented the content, added the images, and make sure that the contact form functions make sure that the links are working, the SEO steps in and says,” Okay, what is this page for? Is it a navigational page? A commercial page? An informational page? Or a transactional page?”
And then the SEO might say, “Okay, so we need to build a couple of pages’ cuz you’ve got a great transactional product page, but this transactional product page has no chance of appearing on Google search.” Not the way you’ve built it, right? ‘Cause they might say. “You don’t have enough content. You don’t have a schema. You don’t have this, you don’t have that.”
How SEO and Web Development Work in Harmony
Let’s talk about some of the things that your SEOs will cover with your web developers and your IT team. So let’s begin with some basic security.
When working on the security of the website, that isn’t always your web developer. Web developers will know stuff about like some really good web developers will know the server side of the combination. But most web developers will not. IT is usually the expert when it comes to the server side. Like if you tell your web developer, “Oh, I want my website on Amazon Web Services, I want my website on Kinsta.” Most web developers will not know how to do that. It’s some will, but most web developers will not know how to do that.
The setup of a staging environment for a website is done by IT. Setting up the initial security for the website like making sure you put up a domain that says HTTPS versus HTTP, which matters to an SEO, by the way, is IT. So IT takes care of that.
Once security is set up and then the site is built, the next thing that the SEO will check for is functionality. Now this thing, web developers actually will cover, right? When we say functionality, what we do is take a look at the response codes there. There are a couple of response codes that you wanna be familiar with like meaning, when we ping a server, the server sends us a coded message back. The coded message is usually a 200 message, a 300 message, a 400 message, or a 500 message.
I’m not sure if you’ve ever seen anybody do this, but when you ping a website from a command prompt, it will tell you the received and then a pingback and then the latency time it received the pingback. But it will say response status, 200, 301, 404, right? And a 200, end of 300 are probably the best results you can get.
The status code you wanna get back from a server is 200. You look for a page and you find the page, a 200 code. And a web developer can fix that, and SEO can also fix that. And so this is where people are getting confused, right? When a website has a 400 error code, right? A 400 error code means a user tried to get to a page but did not find the page, that’s a 400 error code. That’s a 400 status code. Somebody tried to get to a page and could not find the page.
Now. the worst result is a 500 error. It’s an undefined server error, meaning a browser, or a user agent tried to talk to a website and the server, you didn’t even pull up the page, right? The server was down so there’s an unresponsive server and so you get a 500 server error. 500 server errors are not addressed by web developers, they’re addressed by IT.
The next item that the SEO will audit on a website is redirections. Why do you need to do redirections? You probably don’t need to do redirections if you’re building a brand new website, meaning it’s the first time this domain has ever existed. But, if you’re building a new website, you will need to redirect ‘cuz your old websites might have pages that earn backlinks and you wanna transfer that authority over to the new website. That’s one.
Another reason you might wanna do redirections is you might have broken your website apart into several microsites, and now what you want to do is reconsolidate them back into one place.
- Robots.txt file
The robots.txt file is just a textual command inside the folder of your website, which essentially tells all browsers, and all users, including Google where it’s allowed to scan the website and where it’s not allowed to scan the website. Developers are not very skilled at managing robots.txt files. They understand what it is and they understand why it’s needed, but they don’t know… they don’t really appreciate why it’s important.
So Robots.txt files are best administered by SEOs. The SEO has to take a look at, whether are there conflicting commands on a robots.txt file. Are there resources being prevented by the robots.txt file? Are there pages I wanna rank where that page will not get indexed because of the robots.txt file? The person that’s supposed to prescribe the robots.txt file is your SEO. The person that’s supposed to implement your robots.txt file is your web developer.
- Site Map
Now, what about the site map? The site map does not even need IT, right? And in most cases, it does not need your SEO, or sorry, your web developer. It only needs your SEO. Now, what is a site map? Try to do this yourself. Try to do the site colon, and then the brand that you’re working on. If you are one of those websites where you sell a product or a service, you’ve got commercial pages. But when you do that, the first pages you see are a blog, a commercial page, and a press release. That’s problematic.
The reason that happens is that you’re not telling Google which pages are the most important. So Google is prioritizing on its own, it’s making a guess, and that guess is based on which pages attract more users. So if you wanna tell Google, “No, here are my most important pages. I want you to scan my website from most important page 1 to most important page 2 to most important page 3.” You do that prescription from the site map. So your site maps are SEO responsibilities? Yes. Some web devs can be good at this, but you know, the person that prescribes which pages are the most important is your SEO.
- URL prescriptions
Your web devs will build URLs without consideration for SEO rankings, and that’s why you see websites with domain.com/categories/goladelecuk, right? You’re going to see alphanumeric characters that are not readable, and that don’t make sense. Web developers will do that because they don’t understand the implication of randomness in a URL and SEOs do.
Should URLs always be readable? Yes. Do I think web developers should always be mindful of the SEO implication of a URL? Absolutely. But right now, they’re not trained to do that right out of the gate, right? And so it is still SEOs that go in and say, “This URL would be better if you wrote it this way.” Your URL changes have to get given to the web developers to implement. And SEO is also able to implement URL changes. But most of the time, the responsibility belongs to SEO.
- Mobile friendliness
An SEO can figure out why a website is not mobile friendly, or when Google deems something is not mobile friendly. But this requires changes in the HTML and CSS of the website, or in short, the front end facing side of the code. SEO can identify what makes a website mobile-friendly, but a web developer implements those strategies, right? So mobile friendliness is a collaboration between SEOs and web developers.
- Site speed
There are some things that an SEO can do to speed up a website like enable caching. And SEO can evaluate whether the server is poor, meaning it’s super slow and they can recommend, “Hey, you need to upgrade servers because the server you’re working on is too cheap. You’re never gonna get a fast website with that.” So the SEO can do that too but site speed is usually a collaboration between IT, web developers, and SEOs.
The SEOs identify what needs to get sped up on the website. It might be because the images are too large, so the web dev has to change the compression. But if the slowness on the website happens on the server side, it is IT. So anything server side is IT and then anything that is file related is a web developer. The strategy is created by SEO.
- Header tags
You don’t need your web developer for this. If your SEO has access to your website and your website is run on a content management system, your SEO can edit your heading tags by themselves, and there really isn’t any need to bother your web developer or your IT people for that.
Key Takeaway: Your Web Developer is Not Your IT
Berns San Juan: So I’m hoping with this very quick discussion about web devs and SEOs, right? And while your web dev is not your SEO, we shed some light on who you approach in terms of getting help for a specific thing. And you know, I threw IT in there as a bonus because let’s face it if your web developer is not your SEO, your IT is not your web developer, right? And your web developer is not your IT.
So with that, I hope we shed some light on something that confuses brands, businesses, and marketers, and I hope you enjoyed this episode of the Truelogic DX Podcast as much as we enjoy producing it for you.
Thank you for joining us. We always look for any shout-outs, collaborations, and topics you would like to see discussed in future episodes. We are on social media. We’re listening. Give us a shout-out. Subscribe to our Spotify, Google, and Apple accounts and set up your alert for new episodes. I’ll see you in the next episode. Thank you very much. Cheers.