Tag Archives: page load time

It was once commonplace for developers to code relative URLs into a site. There are a number of reasons why that might not be the best idea for SEO, and in today’s Whiteboard Friday, Ruth Burr Reedy is here to tell you all about why.

For reference, here’s a still of this week’s whiteboard. Click on it to open a high resolution image in a new tab!

Let’s discuss some non-philosophical absolutes and relatives

Howdy, Moz fans. My name is Ruth Burr Reedy. You may recognize me from such projects as when I used to be the Head of SEO at Moz. I’m now the Senior SEO Manager at BigWing Interactive in Oklahoma City. Today we’re going to talk about relative versus absolute URLs and why they are important.

At any given time, your website can have several different configurations that might be causing duplicate content issues. You could have just a standard http://www.example.com. That’s a pretty standard format for a website.

But the main sources that we see of domain level duplicate content are when the non-www.example.com does not redirect to the www or vice-versa, and when the HTTPS versions of your URLs are not forced to resolve to HTTP versions or, again, vice-versa. What this can mean is if all of these scenarios are true, if all four of these URLs resolve without being forced to resolve to a canonical version, you can, in essence, have four versions of your website out on the Internet. This may or may not be a problem.

It’s not ideal for a couple of reasons. Number one, duplicate content is a problem because some people think that duplicate content is going to give you a penalty. Duplicate content is not going to get your website penalized in the same way that you might see a spammy link penalty from Penguin. There’s no actual penalty involved. You won’t be punished for having duplicate content.

The problem with duplicate content is that you’re basically relying on Google to figure out what the real version of your website is. Google is seeing the URL from all four versions of your website. They’re going to try to figure out which URL is the real URL and just rank that one. The problem with that is you’re basically leaving that decision up to Google when it’s something that you could take control of for yourself.

There are a couple of other reasons that we’ll go into a little bit later for why duplicate content can be a problem. But in short, duplicate content is no good.

However, just having these URLs not resolve to each other may or may not be a huge problem. When it really becomes a serious issue is when that problem is combined with injudicious use of relative URLs in internal links. So let’s talk a little bit about the difference between a relative URL and an absolute URL when it comes to internal linking.

With an absolute URL, you are putting the entire web address of the page that you are linking to in the link. You’re putting your full domain, everything in the link, including /page. That’s an absolute URL.

However, when coding a website, it’s a fairly common web development practice to instead code internal links with what’s called a relative URL. A relative URL is just /page. Basically what that does is it relies on your browser to understand, “Okay, this link is pointing to a page that’s on the same domain that we’re already on. I’m just going to assume that that is the case and go there.”

There are a couple of really good reasons to code relative URLs

1) It is much easier and faster to code.

When you are a web developer and you’re building a site and there thousands of pages, coding relative versus absolute URLs is a way to be more efficient. You’ll see it happen a lot.

2) Staging environments

Another reason why you might see relative versus absolute URLs is some content management systems — and SharePoint is a great example of this — have a staging environment that’s on its own domain. Instead of being example.com, it will be examplestaging.com. The entire website will basically be replicated on that staging domain. Having relative versus absolute URLs means that the same website can exist on staging and on production, or the live accessible version of your website, without having to go back in and recode all of those URLs. Again, it’s more efficient for your web development team. Those are really perfectly valid reasons to do those things. So don’t yell at your web dev team if they’ve coded relative URLS, because from their perspective it is a better solution.

Relative URLs will also cause your page to load slightly faster. However, in my experience, the SEO benefits of having absolute versus relative URLs in your website far outweigh the teeny-tiny bit longer that it will take the page to load. It’s very negligible. If you have a really, really long page load time, there’s going to be a whole boatload of things that you can change that will make a bigger difference than coding your URLs as relative versus absolute.

Page load time, in my opinion, not a concern here. However, it is something that your web dev team may bring up with you when you try to address with them the fact that, from an SEO perspective, coding your website with relative versus absolute URLs, especially in the nav, is not a good solution.

There are even better reasons to use absolute URLs

1) Scrapers

If you have all of your internal links as relative URLs, it would be very, very, very easy for a scraper to simply scrape your whole website and put it up on a new domain, and the whole website would just work. That sucks for you, and it’s great for that scraper. But unless you are out there doing public services for scrapers, for some reason, that’s probably not something that you want happening with your beautiful, hardworking, handcrafted website. That’s one reason. There is a scraper risk.

2) Preventing duplicate content issues

But the other reason why it’s very important to have absolute versus relative URLs is that it really mitigates the duplicate content risk that can be presented when you don’t have all of these versions of your website resolving to one version. Google could potentially enter your site on any one of these four pages, which they’re the same page to you. They’re four different pages to Google. They’re the same domain to you. They are four different domains to Google.

But they could enter your site, and if all of your URLs are relative, they can then crawl and index your entire domain using whatever format these are. Whereas if you have absolute links coded, even if Google enters your site on www. and that resolves, once they crawl to another page, that you’ve got coded without the www., all of that other internal link juice and all of the other pages on your website, Google is not going to assume that those live at the www. version. That really cuts down on different versions of each page of your website. If you have relative URLs throughout, you basically have four different websites if you haven’t fixed this problem.

Again, it’s not always a huge issue. Duplicate content, it’s not ideal. However, Google has gotten pretty good at figuring out what the real version of your website is.

You do want to think about internal linking, when you’re thinking about this. If you have basically four different versions of any URL that anybody could just copy and paste when they want to link to you or when they want to share something that you’ve built, you’re diluting your internal links by four, which is not great. You basically would have to build four times as many links in order to get the same authority. So that’s one reason.

3) Crawl Budget

The other reason why it’s pretty important not to do is because of crawl budget. I’m going to point it out like this instead.

When we talk about crawl budget, basically what that is, is every time Google crawls your website, there is a finite depth that they will. There’s a finite number of URLs that they will crawl and then they decide, “Okay, I’m done.” That’s based on a few different things. Your site authority is one of them. Your actual PageRank, not toolbar PageRank, but how good Google actually thinks your website is, is a big part of that. But also how complex your site is, how often it’s updated, things like that are also going to contribute to how often and how deep Google is going to crawl your site.

It’s important to remember when we think about crawl budget that, for Google, crawl budget cost actual dollars. One of Google’s biggest expenditures as a company is the money and the bandwidth it takes to crawl and index the Web. All of that energy that’s going into crawling and indexing the Web, that lives on servers. That bandwidth comes from servers, and that means that using bandwidth cost Google actual real dollars.

So Google is incentivized to crawl as efficiently as possible, because when they crawl inefficiently, it cost them money. If your site is not efficient to crawl, Google is going to save itself some money by crawling it less frequently and crawling to a fewer number of pages per crawl. That can mean that if you have a site that’s updated frequently, your site may not be updating in the index as frequently as you’re updating it. It may also mean that Google, while it’s crawling and indexing, may be crawling and indexing a version of your website that isn’t the version that you really want it to crawl and index.

So having four different versions of your website, all of which are completely crawlable to the last page, because you’ve got relative URLs and you haven’t fixed this duplicate content problem, means that Google has to spend four times as much money in order to really crawl and understand your website. Over time they’re going to do that less and less frequently, especially if you don’t have a really high authority website. If you’re a small website, if you’re just starting out, if you’ve only got a medium number of inbound links, over time you’re going to see your crawl rate and frequency impacted, and that’s bad. We don’t want that. We want Google to come back all the time, see all our pages. They’re beautiful. Put them up in the index. Rank them well. That’s what we want. So that’s what we should do.

There are couple of ways to fix your relative versus absolute URLs problem

1) Fix what is happening on the server side of your website

You have to make sure that you are forcing all of these different versions of your domain to resolve to one version of your domain. For me, I’m pretty agnostic as to which version you pick. You should probably already have a pretty good idea of which version of your website is the real version, whether that’s www, non-www, HTTPS, or HTTP. From my view, what’s most important is that all four of these versions resolve to one version.

From an SEO standpoint, there is evidence to suggest and Google has certainly said that HTTPS is a little bit better than HTTP. From a URL length perspective, I like to not have the www. in there because it doesn’t really do anything. It just makes your URLs four characters longer. If you don’t know which one to pick, I would pick one this one HTTPS, no W’s. But whichever one you pick, what’s really most important is that all of them resolve to one version. You can do that on the server side, and that’s usually pretty easy for your dev team to fix once you tell them that it needs to happen.

2) Fix your internal links

Great. So you fixed it on your server side. Now you need to fix your internal links, and you need to recode them for being relative to being absolute. This is something that your dev team is not going to want to do because it is time consuming and, from a web dev perspective, not that important. However, you should use resources like this Whiteboard Friday to explain to them, from an SEO perspective, both from the scraper risk and from a duplicate content standpoint, having those absolute URLs is a high priority and something that should get done.

You’ll need to fix those, especially in your navigational elements. But once you’ve got your nav fixed, also pull out your database or run a Screaming Frog crawl or however you want to discover internal links that aren’t part of your nav, and make sure you’re updating those to be absolute as well.

Then you’ll do some education with everybody who touches your website saying, “Hey, when you link internally, make sure you’re using the absolute URL and make sure it’s in our preferred format,” because that’s really going to give you the most bang for your buck per internal link. So do some education. Fix your internal links.

Sometimes your dev team going to say, “No, we can’t do that. We’re not going to recode the whole nav. It’s not a good use of our time,” and sometimes they are right. The dev team has more important things to do. That’s okay.

3) Canonicalize it!

If you can’t get your internal links fixed or if they’re not going to get fixed anytime in the near future, a stopgap or a Band-Aid that you can kind of put on this problem is to canonicalize all of your pages. As you’re changing your server to force all of these different versions of your domain to resolve to one, at the same time you should be implementing the canonical tag on all of the pages of your website to self-canonize. On every page, you have a canonical page tag saying, “This page right here that they were already on is the canonical version of this page. ” Or if there’s another page that’s the canonical version, then obviously you point to that instead.

But having each page self-canonicalize will mitigate both the risk of duplicate content internally and some of the risk posed by scrappers, because when they scrape, if they are scraping your website and slapping it up somewhere else, those canonical tags will often stay in place, and that lets Google know this is not the real version of the website.

In conclusion, relative links, not as good. Absolute links, those are the way to go. Make sure that you’re fixing these very common domain level duplicate content problems. If your dev team tries to tell you that they don’t want to do this, just tell them I sent you. Thanks guys.

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!

Back in 2011, I wrote a technical site audit checklist, and while it was thorough, there have been a lot of additions to what is encompassed in a site audit. I have gone through and updated that old checklist for 2015. Some of the biggest changes were the addition of sections for mobile, international, and site speed.

This checklist should help you put together a thorough site audit and determine what is holding back the organic performance of your site. At the end of your audit, don’t write a document that says what’s wrong with the website. Instead, create a document that says what needs to be done. Then explain why these actions need to be taken and why they are important. What I’ve found to really helpful is to provide a prioritized list along with your document of all the actions that you would like them to implement. This list can be handed off to a dev or content team to be implemented easily. These teams can refer to your more thorough document as needed.

Quick overview

Check indexed pages

Do a site: search.

How many pages are returned? (This can be way off so don’t put too much stock in this).

Is the homepage showing up as the first result?

If the homepage isn’t showing up as the first result, there could be issues, like a penalty or poor site architecture/internal linking, affecting the site. This may be less of a concern as Google’s John Mueller recently said that your homepage doesn’t need to be listed first.

Review the number of organic landing pages in Google Analytics

Does this match with the number of results in a site: search?

This is often the best view of how many pages are in a search engine’s index that search engines find valuable.

Search for the brand and branded terms

Is the homepage showing up at the top, or are correct pages showing up?

If the proper pages aren’t showing up as the first result, there could be issues, like a penalty, in play.

Check Google’s cache for key pages

Is the content showing up?

Are navigation links present?

Are there links that aren’t visible on the site?

PRO Tip:
Don’t forget to check the text-only version of the cached page. Here is abookmarklet to help you do that.

Do a mobile search for your brand and key landing pages

Does your listing have the “mobile friendly” label?

Are your landing pages mobile friendly?

If the answer is no to either of these, it may be costing you organic visits.

On-page optimization

Title tags are optimized

Title tags should be optimized and unique.

Your brand name should be included in your title tag to improve click-through rates.

Title tags are about 55-60 characters (512 pixels) to be fully displayed. You can test here or review title pixel widths in Screaming Frog.

Important pages have click-through rate optimized titles and meta descriptions

This will help improve your organic traffic independent of your rankings.

The on-page content includes the primary keyword phrase multiple times as well as variations and alternate keyword phrases

There is a significant amount of optimized, unique content on key pages

The primary keyword phrase is contained in the H1 tag

Images’ file names and alt text are optimized to include the primary keyword phrase associated with the page.

URLs are descriptive and optimized

While it is beneficial to include your keyword phrase in URLs, changing your URLs can negatively impact traffic when you do a 301. As such, I typically recommend optimizing URLs when the current ones are really bad or when you don’t have to change URLs with existing external links.

Clean URLs

No excessive parameters or session IDs.

URLs exposed to search engines should be static.

Short URLs

115 characters or shorter – this character limit isn’t set in stone, but shorter URLs are better for usability.

This audit covers the main technical elements of a site and should help you uncover any issues that are holding a site back. As with any project, the deliverable is critical. I’ve found focusing on the solution and impact (business case) is the best approach for site audit reports. While it is important to outline the problems, too much detail here can take away from the recommendations. If you’re looking for more resources on site audits, I recommend the following:

Helpful tools for doing a site audit:

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!

Despite Google’s ambiguity about how it’s used in the algorithm, we’ve seen evidence time and again that there’s a giant ranking factor that SEOs just aren’t optimizing for. In today’s very special Whitebeard Friday, Rand (or Randa Claus) shows us how to fill in this important gap in our work.

For reference, here’s a still of this week’s whiteboard!

Video transcription

Ho, ho, ho. Howdy, Moz boys and girls, and welcome to another special Christmas edition of Whitebeard Friday. I’m your host Randa Claus. (pause) I just can’t keep making fun of Santa like this. It’s just terrible.

I am very thrilled to have all of you with us for the holidays and for this special edition of Whitebeard Friday. We actually have some really important, juicy, meaty SEO material. Hopefully, my beard won’t get too much in the way of that. I feel like I have the same mustache. It’s just whiter this week.

I want to talk about this big ranking factor that a lot of SEO practitioners and experts are almost ignoring. By ignoring, I don’t mean to say we don’t know it exists. We just aren’t optimizing it yet.

That factor is engagement. I’m not just talking about onsite engagement. I’m talking about overall web engagement with your site and your brand. That can manifest in a bunch of different ways. A branded search is certainly one manifestation of that. Direct navigation, so lots of people going directly to your website, lots of people typing in searches for clearly your brand. They want to go just to your website. Time on site and browse rate, we’ve seen a bunch of elements around this. Pogo-sticking, which we’ve talked about on Whiteboard Friday previously. Traffic referrals, meaning traffic you’re sending out to the rest of the web. Google can see this. They have Chrome. They have Android. They have Google Analytics. They have all sorts of plugins. They have the web’s biggest advertising network. They can see all of this stuff. Then, finally, amplification in the forms of press and PR and word of mouth, kind of the non-link forms of amplification, which could even encompass social media.

So what is our evidence that these things are real factors in the search ranking algorithms? Well, unfortunately, unlike the early days of links when this was more directly observable and when the search engines were a little more open about this, they’ve been pretty quiet about engagement. They all talk about it in a broad sense, but they don’t specifically say, “Oh, yes, we specifically use time on site and browse rate.” In fact, they’re very nuanced around this.

The only thing that I’ve heard engineers or search engine folks say is, “Yes, we do use pogo-sticking, and yes, we will look at some forms of amplification and some things around brand,” which you could interpret to mean maybe branded search and some things around brand that could be interpreted as direct navigation. But they are not specific about this.

However, we’ve seen tons of experiments and lots of information that suggest that even if these aren’t exactly what they’re using, they’re using stuff like it. When you see experiments that show, hey, despite the fact that site speed is a very small factor, we reduced the page load time and saw all these wonderful things happen around search. What’s going on there? It’s some form of engagement. It’s something they’re measuring around that, that’s not just site speed, but engagement overall. That increases as you bring page load speed down.

So what’s the problem here? Why is it that SEOs, many of us at least, are not optimizing for this yet? Well, the answers are oftentimes we don’t have the authority. If you go to someone, you pitch an SEO project internally at your company, you’re the person who runs SEO, and they’re like, “No, you take care of our crawlability. You take care of our links. You’re not responsible for how much traffic we send out or the time on site and browse rate or amplification and press.” Those are all different departments, and it’s very tough to get that synchronization between them.

We may not have access to the tools or the data that we need to measure this stuff and then to show improvements. That’s very tough and hard too.

Then the inputs around a lot of this stuff are not direct. Let’s go back to links as an example. If you know that links are the big ranking factor for you, you can show, “Hey, we got this many links. Here’s how it changed our ranking position. We need more. Here’s how we go about getting them.” Plan, execution, analysis, it’s simple. It’s direct. It may not be easy, but it is observable.

This is often indirect. There are so many things that impact this stuff that’s indirect, and that’s really tough and frustrating.

As solutions, it’s going to be our job to do what early SEOs had to do — socialize. We have to go out to the industry, to our colleagues, to our clients if we’re consultants, to other web professionals across all the forms of marketing, and we have to socialize the fact that engagement is a major input into SEO, just like SEOs did starting in about 1999/2000, where we had to explain, “Look, this is how links work. Links are important. It’s not just about getting listed in the directory. It’s not just about keywords anymore. It’s not just about meta tags anymore. Links really matter here. I can show you Google’s PageRank paper here. I can show you all these patent applications here. I can show you the impact of links.”

We have to do that again with engagement. That’s going to be tough. That’s going to be an uphill battle, but I believe it’s something we’re already starting. A lot of industry leaders have done this ahead of this Whiteboard Friday for sure.

Second off, we’ve got to utilize the tools that we do have available to be able to get some of this data, and there are some. While I am no big fan of Google Webmaster Tools — I think a lot of the data in there is inaccurate — we can look at trending numbers around things like branded search, and we can do that through Google Analytics. So Google Analytics, yes, keyword not provided is 90% of your referrals. That’s okay. Take the sample 10% and show over time whether you’re getting a bigger and bigger proportion and bigger and bigger quantities of branded search. That’s a directional input that you can use to say, “Look, our brand is growing in search. There it is.”

You can do user testing around search results. This is something I see very few folks doing. We often do usability and user testing on our websites, but we don’t do them in the search results. If you ask a group of five users, “Hey, go perform this search. Take a look at these 10 results. Tell me which one you would choose and why. Now tell me your second choice and why. Now tell me your third choice and why,” you will get to things like time on site. You’ll get to things around pogo-sticking. You’ll get to those engagement metrics that happen in the search results.

Then, of course, you can use, if you’re a Moz subscriber, Fresh Web Explorer or something like mention.net or Talkwalker or Trackur or something to get these amplification numbers and data that you might not be able to get from raw links themselves. This is gettable data, just in different ways than we’re used to.

Finally, we actually are going to have to change what we’re comfortable with. We’re going to have to get comfortable in a world where the ranking factors are indirectly influenceable, not directly influenceable. That’s weird for us, because we’ve always said, “Okay, algorithm has all these factors. I can influence these ones. That’s the ones I need to work on. I’m going to go to work.”

Now we have to go, “Wait a minute, wait a minute. In order to influence traffic referrals, I’m going to have to do things around my content, things around how I earn traffic, and then, boy, I don’t know if that’ll have a direct impact on my rankings.” You don’t. This is a world of indirect inputs. This thing, this tactic I’m going to pursue is going to lead to this thing, which I hope is going to lead to engagement, which I hope is going to lead to rankings.

That’s frustrating. It’s harder to sell. It’s harder to invest in, but, oh man, the ROI is there. If you can do it, if you can earn that buy-in, you can make these investments, and then through experimentation, you can learn what works for you and where you need to move the needle. This is going to be weird because it’s a world where our tactics are correlated, but they aren’t explicitly causal into the ways that we influence the rankings. It’s a whole new world, but it’s about to be a new year, and I think it’s a great time for us to invest in engagement.

With that, happy holidays, whatever holidays you celebrate. Happy new year if you celebrate the new year. I’m looking forward to seeing lots of you here on Whiteboard Friday in 2015. Take care.

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!

SEO experts spend multiple hours a week reading blogs, social media and forums to stay abreast of the latest search engine developments; we spend even more time testing and measuring tactics to figure out what works best for our sites. When you spend so much of your time thinking, talking and learning about SEO, you can get lost in the echo chamber and take your eyes off the prize of growing your clients’ businesses.

It’s easy to get excited about the new and shiny developments in search and to hang on Google’s latest announcements, but there’s no point in switching a site from HTTP to HTTPS if it doesn’t even have appropriately keyword-rich title tags. There’s no reason to run a button-color conversion rate optimization test on a site that’s still using the manufacturer’s default description on product pages. Sometimes your traffic is plummeting because you haven’t checked for new 404 errors in 6 months, not because you’ve been hit with a penalty.Think horses, not zebras, and don’t forget one important fact: Most people have no idea what we’re talking about.

What clients don’t know

Running a business, especially a small business, is way more than a full-time job. Most business owners these days understand that they need to be doing something for their business online, but once they get beyond “have a website” they’re not sure of the next step.

Moving back into agency work after several years in-house, I was surprised by just how many businesses out there have never gone beyond that first step of having a website. The nitty-gritty of building a search-friendly website and driving traffic to it still aren’t that widely known, and without the time or inclination to become experts in marketing their websites, most small business owners just aren’t spending that much time thinking about it.

Hanging out in the SEO echo chamber is a great way to stay on top of the latest trends in digital marketing. To win and keep our clients, however, we need to step out of that echo chamber and remember just how many website owners aren’t thinking about SEO at all.

The good

Relatively few people know or understand digital marketing, and that’s the reason we all have jobs (and most of us are hiring). The strapped-for-time aspect of business ownership means that once someone decides it’s time to get serious about marketing their business online, they’re likely to call in an expert rather than doing it themselves.

There are some really competitive industries and markets out there, but there are also plenty of niche and local markets in which almost nobody is focusing on SEO in a serious way. Take a look at who ranks for your target keywords in your local area, using an incognito window. If the key phrase isn’t appearing consistently on the search results page, chances are nobody is targeting it very strongly. Combine that with an absence of heavy-hitting big brands like Amazon or Wikipedia, and you may have a market where some basic SEO improvements can make a huge difference. This includes things like:

Adding keywords to title tags and page copy in an intentional, user-friendly, non-keyword-stuffed way

Claiming local listings with a consistent name, address and phone number

Building a few links and citations from locally-focused websites and blogs

It may not seem like much (or seem like kind of a no-brainer), but sometimes it’s all you need. Of course, once the basics are in place, the smartest move is to keep improving your site and building authority; you can’t rely on your competitors not knowing their stuff forever.

Even in more competitive markets, a shocking number of larger brands are paying little to no attention to best practices in search. Many businesses get the traffic and rankings they do from the power of their brands, which comes from more traditional marketing techniques and PR. These activities result in a fair amount of traffic (not to mention links and authority) on their own, but if they’re being done with no attention given to SEO, they’re wasting a huge opportunity. In the coming years, look for SEO-savvy brands to start capitalizing on this opportunity, leaving their competitors to play catch-up.

From inside the echo chamber, it’s easy to forget just how well the fundamentals of SEO still really work. In addition to the basic items I listed above, a website should be:

Fast. Aim for an average page load time of under 5 seconds (user attention spans start running out after 2 seconds, but 5 is a nice achievable goal for most websites).

Responsive so it can be viewed on a variety of screens. Mobile is never getting less important.

Easy to navigate (just as much for your customers as for Google). Run a Screaming Frog crawl to make sure a crawler can get to every page with a minimum of errors, dead ends, and duplicate content.

Unique and keyword-rich, talking about what you have in the language people are using to search for it (in copy nobody else is using).

Easy to share for when you’re building awareness and authority via social media and link building.

So life is good and we are smart and there’s a lot to do and everything is very special. Good deal, right?

The bad

SEO being a very specialized skill set has some serious downsides.Most clients don’t know much about SEO, but some SEOs don’t know much about it either.

There are a ton of great resources out there to learn SEO (Moz and Distilled U come to mind). That said, the web can be a ghost town of old, outdated and inaccurate information, and it can be difficult for people who don’t have much experience in search marketing to know what info to trust. An article on how to make chocolate chip muffins from 2010 is still useful now; an article on PageRank sculpting from the same time period is much less so.

Outdated techniques (especially around content creation and link building) can be really tempting for the novice digital marketer. There are a ton of “tricks” to quickly generate low-quality links and content that sound like great ideas when you’re hearing them for the first time. Content spinning, directory spam, link farms – they’re all still going on and there are gobs of information out there on how to do them.

Why should we care?

So why should we more experienced SEOs, who know what we’re doing and what works, care about these brand new baby n00b SEOs mowing through all this bad intel?

The first reason is ideological – we should care because they’re doing bad marketing. It contributes to everything that’s spammy and terrible about the internet. It also makes us look bad. The “SEO is not spam” battle is still being fought.

The second reason is practical. People billing themselves as SEOs without knowing enough about it is a problem because
clients don’t know enough about it either. It’s easy for someone engaging in link farming and directory spam to compete on price with someone doing full-scale content marketing, because one is much, much more work than the other. Short-term, predictable results feel a lot more tangible than long-term strategies, which are harder to guarantee and forecast. Not to mention that “X dollars for Y links” guy isn’t going to add “There is a risk that these tactics will result in a penalty, which would be difficult to recover from even if I did know how to do it, which I don’t.”

How can we fix it?

SEOs need to educate our clients and prospects on what we do and why we do it. That means giving them enough information to be able to weed out good tactics from bad even before we make the sale.It means saying “even if you don’t hire me to do this, please don’t hire someone who does X, Y or Z.” It means taking the time to explain why we don’t guarantee first-page rankings, and the risks inherent in link spam. Most of all, it means stepping out of the echo chamber and into the client’s shoes, remembering that basic tenets of digital marketing that may seem obvious to us are completely foreign to most website owners. At the very least we need to educate our clients to please, please not change the website without talking to us about it first!

Since terrible SEO gives us a bad rep (and is annoying to fix), we also need to actively educate within the SEO community. Stepping out of the echo chamber in this case means we need to spend some time talking to new SEOs at conferences, instead of just talking to each other. Point brand new SEOs to the right resources to learn what we do, so they don’t ruin it for everybody – for heaven’s sake, stop calling them n00bs and leaving them to learn it all from questionable sources.

As SEO content creators, we should also take time on a regular basis to either update or take down any outdated content on our own sites. This can be as simple as posting a notification that the info is outdated or as complex as creating a brand new resource on the same topic.If you’re getting organic search traffic to a page with outdated information, you’re passively hurting the state of SEO education. A declared stance on providing up-to-date information and continually curating your existing content to make it the highest quality? Sounds like a pretty strong brand position to me, SEO bloggers!

Some people are going to read this post and say “well, duh.” If you read this post and thought it was basic (in every sense of the word), go out right now and fix some of your blog posts from 3 or 4 years ago to contain the latest info. I’ll wait.

The takeaways

There are still a ton of markets where just the basics of SEO go a long way.

Don’t get distracted by the latest developments in search if the basics aren’t in place.

Brands that are getting by on their brand strength alone can be beaten by brand strength + SEO.

Old/bad SEO information on the web means people are still learning and doing old/bad SEO, and we’re competing with them. Branding and positioning in SEO needs to take this into account.

Clients don’t know who to trust or how to do SEO, so we have to educate them or we’ll lose them to shysters (plus it is the right thing to do).

Bad SEO gives all of us a bad reputation, so education within our community is important too.

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!

Conventions and disclaimers

Before we start, a quick note on naming. Beside TLS, you may have also heard the term SSL.SSL was the original encrypted connection protocol created by Netscape in the mid ’90s. TLS is the industry standard protocol that grew out of SSL and has continued to evolve and improve while development of SSL has ceased. In the past, SSL and TLS have been largely interchangeable terms. However, the final version of SSL, SSLv3, was recently found to be not secure. All versions of SSL now have known security problems and no one should be using any version of SSL. To avoid confusion, we will not mention SSL again, and will talk exclusively about TLS.

Finally, any type of guide, tutorial, or how-to post on security is highly time sensitive. Attackers are constantly evolving and new attacks are always discovered. Advice about optimizing TLS performance from even 2 years ago, such asusing RC4, would today leave your site unsecured. You should always maintain vigilance and make sure you trust your sources.

TLS Areas that need TLC

There are 2 areas of TLS that can harbor performance problems:

Encrypting the data. Data sent back and forth between visiting web browsers and your web server must be encrypted and decrypted. If not configured properly, your page load times can become much slower than unencrypted traffic.

Establishing a secure connection. There are several steps that must occur before a browser establishes a secured connection to your website: identities must be confirmed, algorithms must be selected, and keys must be exchanged. This is known as the TLS Handshake, and it can have a significant impact on your site performance.

We need to give each of these areas some Tender Loving Care (TLC) to optimize for performance. Let’s discuss each in detail.

Optimizing Data Encryption

When you use TLS, you are adding another 2 steps to the process of how a browser and web server communicate. The sender has to work to encrypt the data before transmitting it, and the receiver has to decrypt the data before it can process it. Since these operations are occurring on all of your web traffic all of the time, you want this exchange to be as efficient as possible.

There are alarge number of ciphers that can be used to perform this encryption/decryption. Some, such as 3DES, were originally designed to be implemented in hardware and can perform slowly when implemented in software on your computer or phone’s browser. Others, such as AES, are so popular that CPU makers like Intel have added dedicated instructions to their chips to make them run faster.

A decade ago, TLS data encryption added significant overhead. Today,Moore’s law and dedicated support for certain ciphers in CPUs has essentially eliminated this overhead, provided you select the right cipher. The consensus from both security engineers and administrators that run large TLS websites is to use AES, with 128 bit keys. We can see from the chart below that AES running on a CPU that supports built-in AES instructions (denoted by the label AES-NI) is by far the fastest cipher you can use.

Specifying which cipher and options to use can be quite challenging and intimidating. Luckily, Mozillamaintains an excellent page with example cipher configurations to ensure fast and secure connections. These example configurations work with all browsers, and they default to using the faster algorithms like AES. These are constantly updated when new security threats come out, and I highly suggest following their guidance.

As mentioned, to get the most out of AES, your web server will need to use a CPU that supports the dedicated AES instructions known asAES-NI. Most server-grade CPUs made in the last 5 years, such as Intel’s Xeon line, support AES-NI. However, older virtualized servers and cloud servers often don’t support these instructions. Amazon’s M1 class of EC2 instances does not support AES-NI, whereas Amazon’s current class of M3 instances do. If you are using a hosted service, check with your hosting provider about what TLS options they support and whether your hosting computer supports AES-NI.

In short, by configuring your web server to use AES ciphers and terminating your TLS connections on a machine with CPU with support for AES-NI instructions, you can effectively mitigate the performance penalty of data encryption.

Optimization Checklist

Verify that web server is running on a system with a CPU that supports AES-NI instructions.

Optimizing the TLS Handshake

The TLS handshake is the process that the browser and server follow to decide how to communicate and create the secured connection. Some of the things that happen during the handshake are:

Confirming the identity of the server, and possibly the client

Telling each other what ciphers, signatures, and other options each party supports, and agreeing on which to use

Creating and exchanging keys to be used later during data encryption

The TLS handshake is shown in this rather technical-looking diagram:

Don’t worry. While there are a lot of details in the diagram, the takeaway is that a full TLS handshake involves 2 round trips between the client and the server. Because of thedifference between latency and bandwidth, a faster internet connection doesn’t make these round trips any faster. This handshake will typically take between 250 milliseconds to half a second, but it can take longer.

At first, a half-second might not sound like a lot of time. The primary performance problem with the TLS handshake is not how long it takes, it is when the handshake happens. Since TLS handshakes are part of creating the secure connection, they have to happen before any data can be exchanged. Look at the waterfall diagram below: (if you need help, check outhow to read a webpage waterfall chart.)

The TLS handshake, shown in purple for each step here, is adding 750 ms of delay to the time it takes to get the initial HTML page. In this example, getting the HTML page over TLS takes twice as long as getting the same page over an unencrypted connection! Worse, the browser can’t do anything else until it gets this initial HTML page. It cannot be downloading other resources in parallel, like CSS files or images, because it hasn’t gotten that initial HTML page telling them about the other resources. This is true with every secured webpage you visit: The browser is blocked from getting that first HTML response. Unfortunately, the TLS handshake increases the amount of time where the browser can’t do anything, slowing down your site performance.

Also, remember the TLS handshakes happen at the start of every new HTTP connection. Since browsers download resources in parallel, this means that a visiting browser will create multiple TLS connections and have to wait for multiple handshakes to complete, even with visiting a single page!

Unfortunately, there is not a lot of extra or unnecessary data that we can optimize during the TLS handshake. The primary aspect we can optimize is the“confirming the identity of the server” step. To do this, the browser looks at something called the certificate chain.

The certificate chain

When you visithttps://www.example.com, how do you know you are really talking to www.example.com? TLS certificates solve this problem. You receive a certificate telling your browser “yes, this is www.example.com. trust me.” But how do you know you can trust the certificate the server sent?

This is where the certificate chain comes in. Your certificate will be digitally signed by some other entity’s certificate, which essentially says“example.com is cool, I vouch for it, here is my certificate.” This is called an intermediate certificate. Browsers come with a built in a list of a thousand or so certificates that they trust. If the browser happens to trust this intermediate certificate, we are done. However, it’s possible the browser doesn’t trust your website’s certificate, or the intermediate certificate.

What happens then? Simple! The browser will then look to see who signed the intermediate certificate, and who signed that one, and so on… Basically the browser will “walk” up this chain of certificates, seeing who is vouching for who, until it finds a certificate of someone it trusts from that built-in list mentioned above.

The certificate chain looks something like this:

Here we see a certificate for my websiteapp.zoompf.com. My certificate was signed by the certificate by “DigiCert Secure Server CA.” The browser does not trust this certificate since it’s not in its pre-built list. However, the “DigiCert Secure Server CA” certificate was in turn signed by the “DigiCert Global Root CA” certificate, which is in that list and is thus trusted. So in this case, my certificate chain length is 3.

You can optimize your site performance by making this certificate chain as short as possible, since validating each certificate in the chain takes extra time. Additional certificates also means more data that has to be exchanged while establishing the secured connection. The browser might even need to make additional requests to download other immediate certificates, or to check that each certificate in the chain is still valid and hasn’t been revoked.

When shopping for an TLS certificate, ask the vendor:

What certificate will be used to sign your certificate, and how long will the certificate chain be?

Will they include their intermediate certificate bundled with your certificate, so the browser won’t have to wait downloading other certificates while walking up the certificate chain?

Do they support OCSP stapling, to reduce the time needed to check for revoked certificates?

I recommend purchasing your certificate from a large, well known vendor. These tend to offer better support and features like OCSP. They are also more likely to have their root certificates trusted by the browser and thus have a shorter certificate chain length. You can learn more abouthow to test your certificate chain here.

Optimization checklist

Minimize the length of your certificate chain.

Verify that any immediate certificates are bundled with your certificate.

Get a certificate that supports OCSP, if possible.

Avoiding full TLS handshakes

At its heart, the TLS handshake is about the client and the server verifying each other, agreeing on a common set of ciphers and security options, and then continuing the conversation using those options. It seems silly that a client and a server that have recently communicated before need to go through this full process over and over again. Imagine this scenario: You are visiting a blog like this one over TLS. Multiple TLS connections with multiple handshakes were made to download all the content. In a few minutes, you click a link to read a different page on this site, which causes your browser to do multiple TLS handshakes all over again.

This is where TLS session resumption comes in. Basically, TLS session resumption allows a client to say,“Hey server, we communicated a little while ago and did so using the following TLS options… Is it OK to start talking again using those same options?”This is a huge improvement on performance. A full TLS handshake requires 2 round trips to create the secure connection. TLS session resumptions allows us to do it with 1 round trip.

The great thing about session resumption is that it is basically a free short-cut. When the client asks the server,“can we use these previously agreed upon settings?”, it does so as part of the first round trip in setting up a full TLS handshake. If the server agrees, great, the short cut is followed and no further handshaking is necessary. If, for whatever reason, the server doesn’t agree to the session resumption request, the TLS handshake continues as normal and completes in 2 round trips. There’s no reason not to use session resumption.

There are 2 different mechanisms to implement TLS resumption. The first isSession Identifiers and the second is Session Tickets. They both do the same thing. The difference between them is primarily which side has to keep track of the previously agreed upon options. All web browsers support both, but some web servers, like Microsoft’s IIS, only support session identifiers. Session identifiers are a slightly older mechanism, and can potentially expose your site to Denial of Service attacks. Enabling either session identifiers or sessions tickets is done via your web server configuration, and is quite easy. Consult with your administrator about getting these options enabled.

Optimization checklist

Enable TLS resumption on your web servers.

If possible, avoid using session identifiers to reduce your exposure to Denial of Service attacks.

Other TLS Options

There are several other TLS options and nuances we are glossing over: What asymmetric algorithm should you use? What key exchange protocol should you use? What key size should you use for your symmetric cipher? Should you be usingperfect forward secrecy? These are important decisions from a security perspective, and everyone’s needs are different. From a performance perspective, these are largely moot. It is best to leave these choices to whomever manages your server, or to follow advice from Mozilla on the page linked above.

Minimizing TLS handshakes altogether

As we have seen, the TLS handshakes, while necessary, can have an impact on your performance:

They can delay the download of critical responses like the initial HTML page.

They can happen multiple times on a single page.

There isn’t much we can do to optimize them.

While session resumption can cut the delay of a TLS handshake in half, it is still best to avoid TLS handshakes altogether. You can do this by minimizing how many HTTP connections a browser makes when visiting your website. Luckily, many traditional front-end performance optimizations that you should be doing anyway can help. This makes front-end performance optimizations even more important on sites secured with TLS. Let’s focus on 4 optimizations that are particularly relevant for sites using TLS.

1. Persistent connections

Persistent connections allow HTTP to make multiple requests over a single HTTP connection. Persistent connections allow the browser to load the page faster because it can make requests more quickly. But it can also cut down on the number of TLS handshakes. Consider this waterfall, which we looked at before:

See how virtually every HTTP request has a purple section? This purple section is the TLS handshake. Why does it keep happening? Because the web server is explicitly closing the HTTP connection, and thus the underlying TLS connection, with every response. We can see this with theConnection: close response header, as shown below:

This is terrible for performance in general, but especially bad for a site using TLS. Your website should be using persistent connections.

2. Domain sharding

Domain sharding is a technique to trick a visiting browser into downloading resources from your website more quickly. It works by having a single web server with different hostnames. For example, your site might be named example.com, but configured to resolve the names static1.example.com and static2.example.com to the same server. Since browsers allow only a limited number of HTTP connections to a single hostname at the same time, using multiple hostnames trick the browser into downloading more content in parallel.

The problem with domain sharding is that the browser doesn’t know thatexample.com, static1.example.com, and static2.example.com are all the same server. It will make new HTTP connections to each hostname, and have to do a full TLS handshake each time. In our example, we are potentially doing 3 times the number of TLS handshakes because of our sharded hostnames. Additionally, session resumption information for connections on one hostname cannot be used by connections to another hostname, even though under the covers all these names refer to the same server.

The net result is that increased number of TLS handshakes caused by domain sharding may offset any advantage gained from downloading more content in parallel. In fact, sharding a TLS-protected website might actually make it slower. This is especially true if you follow the next two pieces of advice, which will reduce the number of items that need to be requested at all.

3. Combining CSS and JavaScript files

Combining multiple CSS or JavaScript files into one or two primary files is a huge front-end performance optimization. Browsers can download one 100 KB file faster than 10 10-KB files. The advantage for TLS sites is that if you are making fewer requests, you are less likely to need additional HTTP connections that will require a resumed or full TLS handshake.

4. Caching resources

The fastest request is one the browser doesn’t have to make. Caching might be the best front-end performance optimization you can make. If I just visited your site, and I’m looking at a second page, there is no reason to download your logo a second time. If you don’t use caching, the browser must check with your website if it is OK to use logo image it has previously downloaded. This is called a conditional request, and it’sbad for performance. Because of the difference between bandwidth and latency, even if you don’t actually download anything from the server, simple sending a request to ask if it is OK to use a logo takes almost as long as just downloading the logo again.

Conditional requests are bad for TLS. You are forcing the browser to create more HTTP connections, and thus perform more TLS handshakes, just to check if the content is still valid. Caching your static resources like images, CSS and JavaScript will have a big benefit and can prevent these additional connections.

Test your site to ensure you are properly implementing front-end performance optimizations.

Summary

Google is now favoring websites that are secured using TLS in search engine rankings. TLS can have an impact on performance and this article has shown you the steps you can take to minimize the impact.

The data encryption overhead for secure connections is largely a problem of the past, thanks to faster CPUs with built-in support for AES cipher operations. The TLS handshake can be optimized by keeping your certificate chain short by purchasing your certificate from a large, well known vendor whose signing certificates on the trusted list instead of web browser. You can speed up subsequent TLS handshakes by enabling session resumption on your server. You can avoid many TLS handshakes all together by implementing common front-end performance optimizations like persistent connections and caching, and avoiding tricks like domain sharding. You can also useZoompf’s free performance report to ensure your website is using AES and is properly implementing the suggested front-end performance optimizations.

In our next blog post we will discuss with intersection of security and performance that Google is creating with its new SPDY protocol.

If you’d like to stay on top of your website performance, consider joining the free Zoompf Alerts beta to automatically scan your website every day for the common causes of slow website performance.

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!

What is the MozBar?

The MozBar is afree browser extension that provides on-page access to Moz’s link metrics and site analysis tools. Over the years it has gained a very popular following and saved a ton of time for SEO’s and Inbound marketers alike. Whilst there are certain features that are only available to Pro subscribers, we try to keep as much as possible free. We think this is the TAGFEE thing to do, plus it really helps people as possible to get acquainted with our brand and our tools.

The MozBar, since its inception in 2008, solves three main problems for its users:

SERP analysis

Site/competitor research

Link profile analysis

Here’s how those features work in version 3!

SERP analysis

As you search Google, Yahoo or Bing, the MozBar instantly shows you valuable statistics about each of the results you see. This new version of the MozBar makes deconstructing SERPs faster than ever.

Create search profiles for different engines and locations

If you are working in local search, the MozBar allows you to create search profiles for specific regions and cities. This allows you to easily switch between a search for “pizza” in Chicago and Seattle without changing your search query.

Export the SERP to a CSV

As you search, easily export into a CSV key data about each SERP including:

URL

Page Title

Description

Detailed link metrics

See Moz authority and search metrics next to each search result

You’ll get an overview of the most important statistics for each result on a SERP without even having to click through to those results.

Site/competitor research

This is another area where we’ve added a significant number of improvements, from on-page analysis to new structured data and markup detection.

See Moz authority and link metrics

For every URL you visit, the MozBar instantly shows you the link metrics at the top of the page, including MozRank, Domain Authority, subdomain metrics and more.

Highlight followed, nofollowed, external, and internal links

Easily spot which links are followed or nofollowed without having to dig through source code.

See important page attributes and elements on the page

The page analysis tools make up some of the strongest features of the MozBar. They allow you to perform an instant on-page audit of any URL you visit. With just a couple of clicks, instantly see important on page factors like title tags, meta description, canonical tags, page load time, HTTP status and more.

Link profile analysis

Detailed information about a page’s inbound links, including quick comparisons to the site’s domain and subdomain, are available at a glance.

What’s new in version 3?

Those of you familiar with the MozBar will notice that version 3 has a new look and design. The redesign is a result of a bunch of customer and design research and has been optimized around the tasks and use cases it is designed to solve. It is also much faster and more reliable. Some exciting new features for v3 include:

See social activity

No more hunting for that social sharing bar on pages you visit: MozBar now includes social statistics fromFacebook, Twitter, and Google+ right on the page.

Validate and preview semantic markup

You’ll get an at-a-glance look at any semantic markup present on a page. Want to make sure a Twitter card is properly set up? No need to send a test tweet; just preview it in the MozBar.

View keyword difficulty on the SERP

One of our most-requested features was the ability to make it easier to check keyword difficulty. Now you can get a keyword’s difficulty on the fly for any search query with a click of the button, right from the search page.

Looking for the Firefox version?

We are still ironing out some last-minute issues in the Firefox version, and will launch it as soon as it’s ready. For now, don’t worry; you can still useversion 2.65.

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!