With so many cooks in the kitchen on any development project, it’s incredibly difficult as an SEO to know everything that is going on to troubleshoot what could go wrong. However, you know who else has that problem? The developers themselves! There has to be way they keep from tripping over each other, right?
In this episode of Rank and File, I walk through Automated Testing and how it can help put safeguards in place for your SEO.
Video Transcription:
Intro
Welcome back ladies and gentlemen to another edition of Rank and File. I’m your host, Mike King, founder and managing director here at iPullRank. So what I want to talk about today is how and why you should do automated testing for SEO.
What is automated testing?
So first, what is automated testing? Well, it’s a way to put some safeguards in place so that if anything new in your code is rolled out, it doesn’t break something that previously existed in the code, like some previous functionality or something to that effect.
And so you might already be thinking like, hey, that might be cool for SEO. So it’s a key part of what’s called test driven development. You build a test for some condition, that you’re expecting to actually work in your code and then you write your code after that so that when you run that code, it continues to follow through on that test condition. And you’re making sure that things work in very modular ways based on, you know, that test that you set up.
And so this is really important for what’s called continuous deployment or continuous integration. So basically this is the idea that development teams are working in a silo by themselves and continuing to roll out new features and new functionality irrespective of what other development teams are doing. And so because you may be working on one big application, this is a way to make sure that you don’t break other people’s functionality by having a series of tests in place that as your code is being deployed, it has to run through to make sure that you haven’t broken that functionality.
Types of tests
And so there’s a series of different test types as UI tests, and that’s when you’re testing basically the complete application or a website. And so it’s the same as what we’re doing when we’re doing like a headless crawl in SEO. And then there’s integration tests that’s making sure all the different systems are working together. So that could be making sure that you’re testing things for, you know, pulling from databases and APIs and all the things that happened at that layer with the application comes together. And then there’s unit tests which tend to be on a specific level. So it could be a specific function or a specific page template or something like that where you’re testing a couple things that function on that level.
So who does these tests? Typically it’s a developer and a QA engineer that tend to be the people that are developing tests and deploying them. And again, like I said, they do test driven development wherein you start from the test first and then you write that actual functionality and make sure that it works. So effectively they sit down and they design a test and then they work through it and make sure that whatever is being made will adhere to the specifications of how that test was supposed to operate.
How do you test?
So how do you test, again, you’re working with different tools. So one of the ones that I come across the most, it’s called Jenkins. And so, you know, you can use that as part of your CI pipeline basically. And then you know, your tests are running as you’re deploying your code and then you get messages to indicate whether or not those tests passed or failed. And so, you know, typically these run, you can run them as you’re developing on your side, on your own machine or you can run them on your, your staging server. And of course you run them before things go into production. So you make sure that things don’t break.
What is the SEO value?
And so what’s the SEO value here? Well, basically you can set up tests for different conditions for SEO and we’ll talk about some specific examples. But imagine that you could put safeguards in place that a developer could not put out new code unless they adhered to those previous fixes that you did for organic search.
How do you make tests happen?
And so how do you make them happen? Well, really that’s where we come to the examples cause you as an SEO, you can’t actually write a test unless you’re a developer as well. There’s some great SEOs that are developers, shout out to all of them. But nevertheless you are more likely going to be in a test planning capacity. So you may work with a product manager, you may work with a QA engineer, you may work directly with a developer to develop test cases. And so I’ve laid some out here in shorthand so you can get an example of what those look like.
So typically when you want to lay out test cases, you’ll have an ID for the test. So we might call this one SEO 001. And so the scenario is that we’re looking for the presence of a meta-description and a unit test. So on the template level we want to make sure that meta-descriptions are firing into this template. And um, the way you do it is basically check that HTML after it’s being run in that code. And so the data in this case is the template itself.
And then the expected result is that the meta-description would be present. And, an example here we may see that actually that meta-description is missing, but nevertheless we would still recommend that would pass rather than fail the build. And so that’s a key thing to talk about here. You can have a test case cause a build to fail. And so what that means is you cannot deploy code until you, as a developer that made that module or function or whatever you want to call it actually pass that test.
So again, it’s a safeguard so that you can make sure developers are always deploying things that will work from an SEO perspective. And so in the second example, we may check for the presence of internal links that are viable so that they’re returning 200 response codes rather than 404’s or 301’s or what have you. And so we would want this to be an integration test because it’s not just on the template level, it’s once the data is being populated in the template, when the page is being rendered.
So the steps here, you want to render the page and crawl it so you can see what’s on there. And then the data is the crawl data that you get back from, you know, crawling those pages. And so the expectation is that it would all be 200’s, but there may be 404’s. So in that case we would want to fail the build because something has been done such that that content being served is not generating viable internal links.
And then another example could be a page speed example. So the expectation is that the page would load in less than two seconds cause that’s one of the aggressive expectations that Google has in the mobile environment and so on. And so that’ll be a UI test because we need the entirety of the page to load. So you need a headless browser to run as part of this test. And so you want to render it and then get that speed test. And then the data is that rendered crawl data or it could just be the speed test data as well. So the expectation is that it would load in less than two seconds. In this case, it actually loads great in three seconds, but nevertheless we would still pass the build because of the fact that there can be network conditions that throw things off when you’re doing that deployment. So it may or may not be a good test to determine whether or not you should fail the build.
And then finally, let’s say where the scenarios that we expect a canonical HTTP header to be on a given page or a series of pages. And so again, this is an integration test because it can’t just be on the template level. Pages actually have to be constructed in return on HTTP response for us to determine this. So the steps are to check that HTTP response after crawling a series of URLs, the data’s the crawl data and the expectation is that that HTTP header for the canonical tag would be, or not canonical tag, the canonical HTTP header, will be present in that HTTP header or response. And the actual is that it’s missing. And so that is enough to fail the build because we know that can create duplicate content issues.
Conclusion
So the whole idea here is that, you know, you have the ability to safeguard what developers will roll out, but of course they’ve got to agree with it and you’ve got to work with them to make it happen. And another thing that you can do is set up an alert system. So you know, going back to the idea of Jenkins, you can have the logs of what happens through Jenkins, you know, piped out to Slack for alerts or piped out to MySQL so you can generate a data visualization of it over time. And this way you’re able to be in the loop and not having to wait until you do your scheduled crawl or something to that effect. So this allows you to be proactive about things that can go wrong in the development pipeline rather than having to be reactive and get people to go back to code that they had recently deployed.
This way you get those alerts in real time or close to real time and you can reach out directly to the developer and say, Hey, you know, I saw that there was an issue. Is there anything that I can do to help and so on. So I hope that helps. I hope that introduces you to a new idea as you can, you know, work better together with developers and you know, they tend to be very open to these ideas because of the fact that, you know, they are thinking in a test driven way and it’s easy to, you know, really work with them and say, Hey guys, like I think that if we try this out, it’s going to save you a lot of time in the future. So hope that helps. See you tomorrow.
Over to you, what are some other ways that you get ahead of the issues that may arise from development deployments?
Leave a Comment