Do You Need to Worry about SEO with WishList Member?

At first glance SEO and membership sites seem to be two entirely unrelated things. When Googlebot encounters a login page, that page is a brick wall that stops it cold, since search engine bots don’t have a way to log into your site. So any content behind an authentication wall is essentially invisible to Google and the other search engines. So when you are setting up a membership site do you need to worry about SEO at all?

Up to this point I had just assumed no. But I was wrong; when I started looking at a WordPress site using the WordPress plugin WishList Member, I ran into a number of issues. Some issues are specific to WishList Member – and I cover those below. But there is also some general SEO friendly practices around managing your content that applies to any membership site that I want to cover as well. Let’s start there.

Will all your content be protected?

Before you create your membership site, get clear on which content should be public facing and which content is protected. By protected I mean that the search engines and human visitors can’t access it without logging in. (NOTE: Security by obscurity – where a page is accessible but not linked into your site – is NOT protected content).

You don’t want to have pages that are at first public and then become protected, without giving some careful thought to the user experience. I’m not going to cover that scenario in depth here, but keep in mind that if you let Google crawl your page and index it – it’s going to send a bad user engagement signal if a user clicks through and bounces right off because they are faced with a login prompt.

For the content that is publicly facing, all the regular SEO considerations apply. You want great content that answers questions and that is optimized for your audience.

The tradeoff that many (including myself) struggle with, is what to protect and what to make publicly available. Should I show one of my favorite recipes that I have created as way to draw organic visitors to my site? Or should I charge for it? These are not always easy questions. I remember a well known internet marketer once saying that all his content was freely available, but if you wanted it packaged into a step by step sequence you had to pay for it. That comment has stuck with me. If you have the time, you can probably find the information you want for free (well most of the time) online, but if you want a fast solution that walks you through the steps, then you probably need to pay for it.

Another helpful way to think of your free content is that it is helping to establish trust with your potential customer. These days, people are not as eager to give you their email address or buy yet another informational product with some evidence that you know what you are talking about and have some value to share. So think of your free content as a way to get people to explore what you offer and hopefully into your product funnel.

Is the login mechanism for your membership site SEO friendly?

What happens when you (or a Googlebot) tries to access a protected page? You get a login prompt right? But what does the search engine bot see? One key piece of information about a page that is important for search engine spiders is the HTTP status code returned in the HTTP headers. This code, which you can’t see in your browser, is part of the information the web server sends back to the requestor (whether that is your browser or Googlebot) when a URL is requested. Fortunately it is pretty easy to “see” the code with a browser plugin such as the Moz bar. Or just pop the URL into httpstatus.io.

When I accessed a protected URL from a WordPress site using WishList Member, I was expecting to see a code like “401 – Unauthorized”. Instead I got a “404 – Not Found” error. And I got the 404 page as well.

A 404 for a protected page is not the end of the world from the SEO perspective, but it’s a really bad user experience for a user expecting to get a login box to get access to the content. Instead the user gets a 404 page instead, which is confusing.

We are straying a bit from SEO here, but here’s what you need to make sure is configured for each page protected by WishList Member is a “Non-Members” (or Login) page that it will route the non logged in user to. In our case this page is called “Oops! Member Only Content” but it could be called “Login Page”. See the screenshot below:

There is additional complexity with archived and dripped pages, so make sure these work as expected.

Once we fixed that, I found the page returned an HTTP status code 200 (which means the page is Ok), which certainly is not ideal for SEO. An HTTP status code 200 tells Google to go ahead and crawl and index the page (which is essentially just a login prompt – not any real content). You really don’t want a bunch of URLs in the Google Index that look almost identical (the login prompt) and are not useful for searchers. That’s just asking for trouble from one of our favorite black and white animals (the feared Google Panda algorithm).

WishList Member is actually “redirecting” you to the “login page” but the browser never sees the redirect. It’s not a true redirect. So it doesn’t seem that WishList Member thought too much about SEO. Maybe they just assumed the protected URLs would never get spidered in the first place? Bad assumption.

So is WishList Member SEO Friendly? Not really.

However there is a relatively easy fix for this. Just add the meta robots “noindex, follow” tag to the members only/login page and none of these protected URLs should end up in the Google index.

If you have a SEO plugin installed like WordPress SEO by Yoast, this is easy to do.

• Edit the Page that you have configured as the WishMember “Login” Page
• Locate the WordPress SEO by Yoast panel and click on the “Advanced” tab
• Set “Meta Robots Index” to “noindex”
• Leaving the radio button set to “follow” is fine

Yoast and WishList Member – not always happy partners

Here’s another little gotcha that we ran into. The popular WordPress SEO by Yoast plugin was installed into the site – and the XML sitemap functionality was turned on. So this means that Yoast created XML sitemap entries for ALL post and page URLs that had been created on the site. However due to the issue above, most of these URLs were returning the Not Found HTTP status code (404).

Here’s a point I would really like to make about XML sitemaps. Don’t just create XML sitemaps that have all your web page URLs in it. Think of an XML sitemap as a map you are giving Google to a party at your house. You want it to visit all the rooms that have been tidied up and ready for guests. You don’t want it poking around your junky garage or basement. So you only want your BEST and most important pages in your sitemap. Not pages that are deleted and no longer found, and not pages that are protected (ie. the kids room is off limits for the party).

So we needed a way to remove those URLs from the XML sitemap. Turns out that Yoast does provide an option to exclude pages from a sitemap.

• Edit the Post or Page you want to remove from the XML sitemap
• Locate the WordPress SEO by Yoast panel and click on the “Advanced” tab
• Set the “Never Include” option for the “Include in Sitemap” setting

You’ll have to do this for each page (unless you can exclude by post type), but once you are done, you are done.

Hopefully this post will save you some time and get your membership site off to the right foot. Any other issues that I didn’t cover? Let me know in the comments.

Credits

A big shout out to Petra of Petra Mayer Consulting who graciously agreed to have screenshots of her WordPress admin shared and helped explain WishList Member to me.