The 5 Most Common Website Bugs Found After a Site Launch [Interview]

Launching a site is one of, if not the most, exciting parts of the entire redesign process.

Seeing the product you and your team worked on so hard come to life is nothing short of sweet.

After you celebrate the launch, however, the one thing you never want to happen occurs…

You check your email and find users complaining to you about issues they are experiencing.

Pages and links are 404ing, certain pages aren’t set live, functionality isn’t behaving, etc. And just when you thought everything was perfect!

I know no one wants to encounter these sorts of issues, so I decided to sit down with two of our developers Tim Ostheimer and Kyle Sheldon, to detail the 5 most prevalent bugs they find once sites have launched.

1. Browser Compatibility Problems

CA: People use a lot of browsers. There is Chrome, Firefox, Internet Explorer etc.

Your website does look differently across all browsers.

Sometimes it's just font thickness and spacing (to a slight degree), but it can also be functionality, especially if a particular browser you're optimizing for doesn’t support sections of your site.

Why do some browsers show our website differently, and which should we be checking to assure ourselves our site works for most users? I want to go to you Tim first.

TO:  I think, specifically, you're asking why Internet Explorer looks bad.

KS: Haha! Yes, Internet Explorer is certainly the most issue prone.

TO: Yeah. Browsers are all built by different companies using different code and really the only reason that your website works in most of them is because of standard practices ways in which the code is actually rendered.

But, each browser is different and contains varying features that render your code in different ways.  

You might have heard the term ‘WebKit,’ which is a particular engine pertaining to newer browsers, Chrome and Safari in particular. These browsers accept more code selectors, while browsers like Internet Explorer and Firefox may not.  

Before building your website, you should check your analytics to see where how your browser traffic is distributed.

For example, if the majority of your traffic is using newer browsers, but .5% is on Internet Explorer 9 and below, you could get away with not optimizing for it, especially if optimizing for it would take more time without a chance of increased business.

There are situations where some companies are required to use older browsers.

Usually, this is for some sort of internal reason. Maybe they have some software that doesn't work on newer versions from Microsoft. If that's the case, then you want to make sure the company can still use the site, even if it is modified.

Do the best you can to optimize as you go. If there are certain bits of code that you know won't work in certain browsers, then try researching a different method. Otherwise, you're setting yourself up for error later on.

CA: What's the best way for people to test browser compatibility when the sites ready for QA?

TO: When you're ready to actually begin optimizing for other browsers, the best way is to view the browser in a real browser but there are other solutions like BrowserStack to create a virtual environment.

What that will help you do is actually see what users using those browsers would end up seeing. Then, you can use their built-in development tools to optimize and figure out which code needs to be adjusted.

One of my favorite JavaScript plugins is Modernizr which allows you to add CSS based on the browser's compatibility.

So, if you're using certain ‘fancy’ CSS3 selectors that Internet Explorer can't read, Modernizr will add some selectors on the page that you can target to style the site differently.

This means your experience on that browser could be different from the modern ones, so keep that in mind for the end-user.

KS: Everyone should be using an auto-prefixing plugin whether it's a sublime plugin, compass mixins, or an online tool like Pleeeeseplay. This will help generate the appropriate vendor prefixes which are a caught of the majority of cross-browser issues.

2. Responsive Website Mistakes

CA: All of us know at this point that you have to make your website responsive. But if you're still in the dark about what that means, you can check out this nifty article to learn more.

When QAing our site, we sometimes get stuck looking at just a couple screen sizes we believe are the most popular and ditching all others.

For example, although 40% of your traffic could view your site on a standard laptop screen size, you could easily be getting traffic from those with viewports as large as 2560px or 4k resolution. If your website looks broken in these environments, it can be pretty embarrassing to discover later on.

So, Kyle, I want to go to you for this point you know. What sorts of mistakes happen with responsive websites and how can you make sure that when you're QAing them that you're not having like little issues say on like mobile, tablet, etc.? 

KS: Well, there's really no substitute for having an actual physical device. If you have the budget for this, I’d recommend an emulation/device lab. That's really the way to go, but it's very impractical even for like mid-level agencies such as ourselves.

Browserstack is very good. It's affordable but can get pricey if you want to have multiple users using the platform at once. Occasionally, Browserstack can be very painfully slow to work with. You can also use the Device Toolbar in Chrome to resize the screen and look at different viewport sizes.

TO: Another thing to point out is there are two types of mobile websites. Usually, you only see responsive websites now, but you may remember seeing adaptive sites in the past.

With a responsive site, you could open it up in a browser and resize the window and you would see the layout change immediately. An adaptive website is either one that loads a completely different set of code based upon what the screen size is on load. You’ll see this with mobile applications and older websites where you may have gone to an e-commerce store.

When it comes to testing responsiveness, I like resizing the window in Chrome. That usually shows me how the site responds at every single pixel size so that I can tell if there are any specific awkward combinations. But as Kyle said there's no substitute for a real device.

You can also inspect element on iPads and iPhones using Safari on the computer. You just have to make sure that you have development mode on or the development toolbar enabled and a wire connected to your computer.

You'll be able to inspect elements and hover over everything and view the code just like you would on the computer, except you can see it all on your phone which really helps to fix certain bugs if there's one that's really troubling.

3. Links and Site Forms Aren’t Doing Anything

CA: Obviously there's a ton of functionality problems that can happen on your site regardless of what kind of thing you're trying to integrate, but I think one of the smaller issues that we tend to overlook is checking all our links, buttons, and forms.

So, Tim do you think you could talk about how thorough you need to get when checking your pages and what you tend to see is the most common linking issues?

TO: Sure. So, a lot of times during the development build out a website the developers will use placeholders for buttons and forms. They're just in there to make the layout look like it should.

This is one reason why linking tends to be forgotten because the page looks right but you actually have to click on buttons or check out the hyperlink to make sure that it's pointing to the right place. The best way to do this is to simply click on everything, but that can take a lot of time and even so you may not necessarily be able to check it in an ideal way, especially if you're using something like a staging environment.

If you are in a staging environment, then that button is most likely just pointing to a URL that doesn't exist until it's live. So, obviously it's a little hard to test because you’ll be sent to a 404 when you click it, but that doesn't necessarily mean the page is or the URL is wrong.

There's always going to be certain situations where you can't completely test something until it's live. So, you’ll want to do the best you can before the site goes live, and once it does, you want to have a team of people combing through the site, making sure everything looks right and functions correctly.

Then there are also tools that you can use to automate this process. One that I would suggest is Screaming Frog. You can also use it to check broken links and 404s when your website is live.

What this tool will do is crawl your entire site, check for any metadata anomalies or invalid properties and return any errors to help you troubleshoot and fix those bugs.

4. Noindex Codes Haven’t Been Removed

CA: So, the next bug I want to talk about is having a ‘NoIndex’ code snippet still on your site after launch.

To preface this section, a no index code is a little snippet of code that you can put on a live page that prevents the site from being crawled by search engines. In development, this snippet can be useful for testing live pages you don’t want others to find but is extremely harmful if left on your site.

Kyle, I want to get your insight on this, what are other scenarios where you’d want to use this?

KS:  The best example of where you’d want to use this is on a Thank You pages where you don't want these pages to show up at search engines. You’d want someone to convert on the landing page attached to these, then arrive on the thank you page with the offer after they convert.  

As Christine mentioned, you can put ‘no index’ when you’re in the middle of developing a site. For example, if you don't have a staging environment, you may need to add that code to live pages to work on the site without people finding the unfinished version.

Right before launch, you want to make sure these tags are removed, that way search engines will immediately begin crawling it and ranking those pages in search results.

Again, you could use a tool like Screaming Frog or SEMRush and check your entire site to make sure that only the pages that you want no index on are no indexed. The same thing applies to your sitemap, any pages that aren't in that are indexed should also be in your sitemap otherwise search engines may have trouble locating those as well.

TO: Internally we actually have a little code snippet which gives us a small notification when loading a page in HubSpot in editor mode that will let us know if the no index tag exist on the page. That way we can easily identify any pages that have the no index tag that should. This is just a little snippet of code that was pretty easy to write. For anyone interested in it, you can reach out to us or comment below and we could send it over.

5. Slow Site Speed Speed

CA: The last bug we’ll be talking about is site speed. I tend to find that this is something people do not think about when they're reviewing their site. They look through it, they think it looks okay, but then they put their site live and they discover their pages have high bounce rates, or their analytics say their site load time is very high.

I heard an interesting statistic actually on ConversionXL. It says ‘47% of people expect a web page to load in two seconds or less’. That is really scary. That means that you like need to have your site incredibly fast and two seconds is a really, really hard number to hit.

Tim, I think you had a lot of experience with people asking you what they can do to speed up their site. What are the things that are making a site slow and what is a quick list of things they should check to make sure their site speed fast?

TO: There are actually multiple checkpoints you want to optimize for. In general, you want to make sure that the page is loading as quickly as possible so the user is able to begin using the site in under two seconds or less.

Usually, the cause of a slow load time is going to come down to media and usually by media I mean images, but on some sites that may include video as well. Media is probably one of the more prevalent resources on the site that will slow your site. When reviewing your site, you’ll want to make sure all that media is as compressed as possible so your site is loading 100kb images, not 1MB ones.

Another thing to be aware of is numbers are requests your site is making, So, these are things like image, media scripts, fonts, pretty much anything that that page is requesting from other web pages to load. If it's requesting things from other servers, this can make an even greater impact on the load time because the user’s browser is not requesting all of the information from a single server. It actually has to reach out from to multiple servers.

You should also compress your JavaScript and CSS files as a way to squeeze out any additional space. And if you don’t know how to do this, there are many tools out there that can help.

KS: Another option is to use a CDN (Content Delivery Network). What this does is post all of your assets on one cached server so that even if you have a bunch of different HTTP requests that would be coming from multiple locations the CDN is able to cache it on their server.

This helps increase the time to render the page because everything is coming from the same location and it doesn't have to download them each time the page is refreshed.

CA: Awesome, that brings us to the end of this interview! Before we close out, I want to ask you guys, are their other bugs you typically stumble upon during QA? How do you make sure they don’t happen? Let us know in the comments below!