6 Things to Check Before the Site Launch

I am absolutely sure that this list will change over time. But I realized this morning that I don’t have a real set list of things to do before I launch a site – be it a redesign or a brand new site. Again, it’s a whole “fly by the seat of my pants” kind of thing. Using experience and memory to help me through it – when really I should have something written down. So here is my first attempt at the things I need to be sure of before a site goes live.

Most of it, I’m sure, will fall under the category of “all sites,” but there will be a few that are different between a brand-new site and one that already exists and is getting redesigned.I should also note that the vast majority of my sites (in fact, all of them, within the last 2 years) have been WordPress sites. So I don’t know how much this list will apply to regular HTML sites (or even sites using other platforms.)

So, let’s have at it.

1. Be absolutely sure you’ve put the Analytics code in the footer.php file.
I just realized this little tidbit this morning. I did my redesign 3 days ago, and checked my GA this morning to see if it did any damage. Lo and behold, I dropped from 300 visitors per day to 2. I think my heart skipped a beat there for a minute. I spent about 45 minutes this morning investigating what went wrong, when it suddenly dawned on my that I forgot to put the tracking code into my new theme. Score 1 point for being an idiot.

2. Be absolutely sure you’ve set your Privacy settings to be indexed.
Please don’t ask me how many times I’ve launched a site and forgotten to uncheck the “I would like to block search engines, but allow normal visitors” button in the Privacy settings of WordPress, thus solidly blocking Google (and others) from indexing a site at all. I need this one (and frankly, #1) tattooed on my arm or something. (Forehead wouldn’t help, since I can’t see it :) )

3. If you write custom functions, make sure they still work on the live server.
I’m actually dealing with this one right now. I’ve written a custom function that allows end users to upload images to a WordPress site. Crazily enough, I’ve had several clients who want this capability. (It started with one client who was running a photo contest, and wanted people to leave submissions in the comments, and another who was a sports trophy site who wanted people to show off their kills.) As of this moment, I have 6 different sites, all on 6 different servers, using this code without an issue. However, yesterday, one reported that it wasn’t working. Found out it’s a server setting that refuses to allow “move_uploaded_file()” or “copy()” to function, because WordPress doesn’t have permission to access the default Apache /tmp directory. I’m still trying to figure out a feasible workaround – but I’d gotten so used to this code working, and on so many different servers, that I just stopped checking. Not all servers are configured the same – so don’t take your code for granted.

4. Check for broken links – especially if you start working from localhost.
I love the WordPress import/export feature, because it typically takes you urls within the whole site and converts them to wherever you’re moving it. So if you work from localhost (I use MAMP – used XAMPP when I was running a PC) you can take your local work and export it to the “live server” and your uploaded images and links will be converted to match your new site. However, this does not qualify for custom fields or widgets. Nor does it do it for your stylesheet. Not that I use the full path for things in my stylesheet – but it’s been known to happen on occasion (like when I’m troubleshooting something) and I forget to remove it. So be absolutely sure you’re not using your localhost as links for anything. The fun part about this too is, because you’re using localhost, YOU will see everything just fine, because it’s all on YOUR computer!

5. Make a nice 404 Page, and make good with the comments.
Both of these always seem to be afterthoughts on sites. Try to make your 404 page useful. There’s tons of good 404 tutorials out there that’ll help you decide the best format for yourself. Comments, too, are something that reflects not only your expertise in thinking of everything, but shows that you really do want feedback from your site users. EVen if the client doesn’t want comments to be enabled on his site, do it anyway – someday he might change his mind, and the fact that you had the foresight to do it will leave a much better impression than forcing him to hire you again.

6. 301 redirects
This is something that applies to already-established sites. I just recently did a very highly ranked site that was very much established, and the client wanted a nicer-looking site with more control. She moved from TypePad to WordPress. AT one point, I asked her to go through and make sure that I kept the URLs the same – I was trying very hard to not change any of them so it would be a seamless transition without the need of 301’s. But even she didn’t think it was any big deal, and when the site went live, her rankings dropped significantly. Quick 301’s fixed the issue – but had we put them in place before the site went live, she probably wouldn’t have experienced such a significant drop. (And also, if I had remembered #1 and #2 up there, it wouldn’t have happened either! LOL)

Now, I need to remember to refer back to this list often so I don’t forget this stuff.

Have your say: