How pre-launch testing for my website redesign saved my bacon

17 Feb How pre-launch testing for my website redesign saved my bacon

This is the sixth post in my series Why Updating Your WordPress Site to Mobile Responsive Will Drive You Insane.

My new content and portfolio examples were ready. My web developer consultant had helped me with the custom coding that I couldn’t work through with the theme developer. I had my some blog posts queued up, including the first: How I Did a DIY WordPress Site Update to Mobile Responsive Without Going Insane.

My new responsive site was ready for the world. All that remained was pre-launch testing.

It was this testing that saved my bacon and revealed I had a dead-site-walking.

A Type of Bacon – by Gage Skidmore [CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons

Website pre-launch testing basics

Pre-launch testing on my site was like the dawning moment a few emails into an online dating correspondence when those niggling issues you’ve been glossing over come right out in the open in all their impossible-to-ignore glory.

There are lots of pre-launch testing and verification steps that have to happen for a WordPress site to be indexed and optimized for search engines. Most of it’s way over my head and this work is one big reason I hired a web developer to do it.

Here’s a list of some of the basics that need to be done before you launch a new site so your site is properly optimized for search.

1. Check for and eliminate bad backlinks.
2. Fix broken links/Page Not Found problems.
3. Activate Google Analytics and Google Search Console (formerly Webmaster Tools), get listed as the owner of the site and verify your website.
4. Set up 301 redirects so people trying to visit your old site URL are directed to the new site.
5. Search for and replace the temporary address code from your cloned/dev site files.
6. Submit a sitemap to Google and other search engines for indexing and unblock robots. (If you’re trying to go it alone, here’s a primer.)

On my site, here were some of the flaws in the Converio theme that became glaring during testing. These ranged from minor to very, very significant.

The blog grid wasn’t mobile responsive.

Some columns weren’t getting formatted as mobile responsive.

Client list columns not mobile-responsive

WooRank indicated my site was performing WORSE than my old site.

WooRank website score for my NEW Converio site about to be launched

WooRank existing website score

There were problems with the structure of H1 and H2 tags.

The title “Blog” was the default H1 for all my posts. For Portfolio projects, my web developer couldn’t find an H1, and on the portfolio page the theme combined the project title and skills all within the H3 tag.

“Blog” as H1

When I raised these issues with Converio tech support, they found reasons outside the theme code at fault:

Me: Why is my mobile Woorank LOWER for my new site than the old?

Converio: “There could be many different reason not strictly related to the theme, but according what we Woorank is showing it’s related to broken links…Other one seems to be related with content duplication of your main homepage. Perhaps woocommerce found the same content on your main website and think that it’s duplication.”

Me: The H1 and H2 structure is wrong.

Converio: “…general importance of h1, h2, etc. in SEO nowadays is very very little. It was used by spammers before and now Google has lowered the importance of h1, h2, etc., so we think now it’s really nothing to be worried…there is really very very slight difference between h1 and h2…We just checked most popular theme on themeforest “Avada” and it seems to use very similar strategy as we are using on Converio…if you want to use h1 as post title then we can change it for you…”

I got an overlong explanation of custom coding instructions about switching to a child theme so I wouldn’t have to recreate all the changes following future updates of the theme.

I conferred with my web developer. If we created a child theme it would wipe out all of the theme settings we’d already set so they’d have to be manually reset. And the theme documentation wasn’t clear how well–or if–Converio supported child themes.

Soon my web consultant and Converio tech support were emailing back and forth on increasingly complex issues and possible fixes. The language barrier (apparently they were in Poland) didn’t help. It began to feel (and I don’t think it was my imagination) that my web developer was having to advise the theme developers on how to do basic fixes to the theme code.

All on my dime.

In the end, I decided to pull the ripcord. Five months, $1300 and about 120 hours of my time into my website rebuild, I decided I needed to abandon Converio and choose a different WordPress theme.

Tough lessons learned in how to select a good WordPress theme

There are now thousands of WordPress themes and it’s hard to tell which have clean coding, decent tech support and future solidity. Reviews aren’t as reliable as they used to be.

I decided to migrate my unpublished new site to Bridge, a theme my web developer already had positive experience with. I put her in charge of re-rebuilding my site using a child theme so I’d be protected from future theme updates that could wipe out any customization she did.

(Be aware that developing a child theme means you’ll probably have costs for maintaining/updating your site to keep it compatible with the parent theme if major changes come down the pike.)

In my next post I’ll share how I measured my new site’s performance against the old. I’ll also provide the bottom line on  the time required, costs, benefits and drawbacks of trying to update your WordPress website to mobile responsive on your own.

Need marketing help? Give us a holler.