What Should You Pay Attention to Before Launching a Website?

As an SEO, you should check many things before launching a website for maximum optimization.

Video transcript:

David: Okay. Uh, so if you go in, I put it under technical SEO. And there is the website launch checklist and the website design best practices.

Dave: Oh, that’s nice.

David: So, whenever I have, because I don’t build websites, whenever I work with a designer-developer, I give them both. Here’s what a good website looks like from an SEO perspective. That’s the website design best practices because this is what we’re going to need out of you to build.

Dave: Yeah.

David: But I also give them the website launch checklist. Because when we launch immediately, this is what I want you working through. And I want you to know how I will be evaluating the website upon launch. Because that helps the developer understand a couple of things. Number one, how they’re going to be judged for success, but also making it very clear what we’re going to be looking at because I am not a fan of launching websites at low traffic times. Mostly because, to me, a website launch is an all-hands-on-deck event. I need the developer present, the client present, and me present. And to find that time when we can all three be looking at the website, and the reason is from an SEO perspective, we have to catch any error before Google does. Because if Google indexes an error, it’s going to be really hard to un-index it. But if we use the web design best practices, we’re setting ourselves up for success. And the website launch checklist has two phases. One is that this is the stuff we’ve got to have in line before. And then the other half of it is literally when you push the launch button, we are starting and checking these things. So, I would love for you to review these. And if you have anything that I’m missing, or if something’s not clear, you can leave a comment at the bottom of the post for me.

Dave: Okay, Brian, you want to do that? And I’ll look through it, too.

Brian: Yeah.

Dave: So, this is one of our goals this quarter, to go through all of your plan and see what we’re missing, what we’re doing right, and what we’re doing wrong in our current SEO.

David: Okay, great. Great. I look forward to your input as well as you encounter things that are unclear. Because I know they’re in there. I laugh about this document, the website design best practices because it’s almost as if every time I write it, I give it to a developer. The developer finds a way around what I’ve recommended.

Dave: Oh, so you don’t. Oh, okay. So, what that means, David, is that do you have an audit process?

David: What do you mean by an audit process?

Dave: So, you’re working with a web designer, right? And you give them this document, and you tell them to do all this stuff. An audit process would be, oh, I better independently check that the guy did what he’s supposed to fricking do.

David: Typically, I recommend several check-ins during the process, and I want to look at the code. So, I’ll look at the wireframe. Right? And I’m going to look at design practices, and almost universally, the wireframe problem is they’ve done it desktop-first design rather than mobile-first design.

Dave: Okay.

David: Alright. Almost always. We’ve got to rethink the way we do it. Google is mobile-first. We have to think mobile-first design perspective. They love to get up and look for calls-to-action, and you know, blocks of text, and just stuff that’s designed. And so, I want to be part of the wireframe approval process.

Dave: Okay.

David: Second of all, I recommend at least one check-in before launch to look at the code as rendered on the dev server. Understanding that, hey, this isn’t the final forum, don’t have too big of a problem, David. But, just knowing, hey, we’re using a JavaScript framework that’s not crawlable or something like that, that somebody’s read, oh, a Google can read this, because I read in one article somewhere, you know?

Dave: I was going to say, have you ever, so I’ll go through this, and Brian will too, but have you ever thought of offering this as a service?

David: Oh, I do it all the time.

Dave: No, but I know you do it, but do you offer it as a service and advertise it and all that?

Tricia: You mean separately other than clients?

Dave: Yeah. It’s like, hey, for $200 or $500, or whatever it is, I’ll do an SEO audit.

David: Oh, yes.

Dave: Okay.

David: Yeah, I do it through Reliable Acorn.

Dave: Yeah. Okay. Right.

David: Yeah, because that’s my main business, but I’ve been hired for that explicit purpose many times. And it’s a thankless job, frankly, because your job is to go in and say, “Hey, Captain Hindsight here, you should’ve done it this way.” This is not a very grateful job. But the last important piece of this is I always ask for an audit right before launch. So, in other words, I asked for the developers to be done. Give me a week after the developers are hands-off for me to look at a dev server before you launch. Because again, we have to catch problems before Google does. So, especially on a really big website, I want to make sure there’s not a fundamental problem going on there. And not everyone’s willing or able to give me that. But if they won’t give me that, then I absolutely fall on the sword and insist that all hands are available upon launch, including the dev team, to fix problems as we find them. Because we are going to find problems, it’s okay. I joke like this because developers have one perspective to success in a website launch, which is, does it work? Does it look good? Does it render as I’m expecting it to render? That’s success to dev, even as a designer. For me, as the SEO, success is how does Google look at it? And devs don’t always know how Google looks at piece. And sometimes, they think that’s outside my scope. So, SEO is an add-on service you’re paying for. So, they don’t think about it that way, but my job is to be the Google advocate. So, you might have made the decision to update and change all the URLs and not tell me. And I’ll be like, whoa, stop everything. We’ve got to put a thousand redirects in place, right?

Dave: Yeah. Yeah. Well, I’ll just say something. So, um, what happened recently and, and Brian knows this is, we had the strangest thing at a client whose website we did years ago. And then, they hired another marketing firm to do their website, but they still wanted us to host it. I’m like, okay, well, let me look at it first, but essentially yeah, they redid it and everything. But they are a marketing firm, and I don’t guess they’re doing SEO, but Brian, it might be good for us in the next couple of weeks to test out David’s best practices against the new straight source.com design. And then we can do that, and then we need to do it against our Verdyn Park’s design, as well.

Brian: Yeah.

Tricia: I would, I mean, I know you’re doing that, but in the future, I would be a little bit leery of just doing the hosting when you were doing everything. Because I’m almost afraid of what happens if an issue comes in there, and they say, well, it’s your hosting, and you know it’s not.

Dave: You’re right. And normally, I don’t do it. This is because, you know, a long-term client, simple website. I don’t anticipate too many problems. Although we ran into one that was crazy. Idiot. They relocated the content directory instead of WP dash content. You can do that with WordPress. They relocated it to a different place. And so, Brian and I were talking about it, and Brian said, yeah, it looks like that’s an old practice for security reasons. The box looking at WP dash content it’s at content and somewhere else. But Nathan was saying, you know, everything is smart enough now to crawl.

Tricia: Yeah.

Dave: So, yeah. Um, so it’ll be good to do that.

Tricia: Yeah.

Dave: That’ll be good for a client so that they get an independent view from us of, hey, did this new company do what they said they were going to do?

David: Right. I think you guys, as a web dev shop, should invest in a copy of Screaming Frog and get a copy of their site before. So, you know, when I write Curious Ants, I write it because I want to focus on free tools and not try to get everybody to buy the expensive tools. But with this process, I use it as written, using Screaming Frog, because I kind of don’t know how else to do it and keep up with all the URLs. And so, what I will do is get a copy of the site before the launch and copy the site afterward. And then you find things like, oh my gosh, they turned on the feature in Yoast to remove stop words. Now all the URLs are changed. You know, it sounded good. It’s in the SEO plugin. It must be right. And maybe it’s fine, but now you’ve changed all your URLs. And so now you have to put a bunch of redirects. Things like that are well-intended accidents. If there’s one thing that’s super, super important about launching new websites unless they have a really, really super good reason, don’t change the URLs. And when I say change, I mean slash or not at the end, you know, so many websites tanked because they messed up their HTTPS transition and at one little ass in there screwed everything up. That’s the most important thing.


Have a question about this process? Ask it here: