Welcome to the Q&A Forum

Google Keyword Planner - https://adwords.google.com/KeywordPlanner

Keyword IO - http://keywordtool.io/

Word Stream - http://www.wordstream.com/keywords

Word Tracker - http://www.wordtracker.com/

More great ideas here - http://www.seerinteractive.com/blog/spark-new-ideas-with-these-keyword-research-toolstips/

and here - https://moz.com/beginners-guide-to-seo/keyword-research

and here - https://moz.com/blog/category/keyword-research

Either way it is going to end up being a huge pain in the butt.

How come no one else jumped on that?

Use of the canonical link should solve all of your problems as far as how the search engines.  Bots that view the PF page will take the canonical directive and treat it like a 301 redirect and pass link equity etc.

The other thing you need to consider is the use of rel next and prev for the article that you broke into parts if you consider this one big article broken up into parts.  That would be used to "connect" all the sections of your depression article to each other.

Frankly, I do not know why you broke up this page into parts as the article is not that long as a whole  There is some data out there that longer articles get more links http://www.quicksprout.com/2012/12/20/the-science-behind-long-copy-how-more-content-increases-rankings-and-conversions/

One issue on the print pages is that you have a meta noindex tag. That tells Google to deindex the page and not to crawl it.  You do not need to use that tag as you are using the canonical to tell Google what the "parent" page.  If you are using the rel next prev on both the regular and paginated pages, I would advise canonicaling P1 to P1, P2 to P2 and the All to the All page vs canonical everything to the main page.

You are basically telling Google two things.

1. with rel next prev - here are the parts that make up the whole.

2. with the canonical - if they look at the PF version, here is the "real" page they want to pay attention to.  This is what passes the link equity along to the proper pages.  If you are getting links into the "print all page" this is the key page to have canonical linked to the "real" page.

What I would do is put this all into one page and then it is simple.  Just canonical the PF page to the actual page and remove the noindex meta tag off the PF page.

If the above does not make sense, read each of the articles below about 3x and watch the video 3x it should help

Here are the Google Pages on canonicals

http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html

and rel next prev

http://googlewebmastercentral.blogspot.com/2011/09/pagination-with-relnext-and-relprev.html

http://googlewebmastercentral.blogspot.com/2012/03/video-about-pagination-with-relnext-and.html

Good luck!

According to Matt Cutts

http://searchenginewatch.com/article/2281151/Matt-Cutts-Short-Website-Downtime-Wont-Hurt-Your-Search-Rankings

"According to Google's Distinguished Engineer Matt Cutts if your website is down just for a day, such as your host being down or a server transfer, there shouldn't be any negative impact to your search rankings. However, if the downtime is extended, such as for two weeks, it could have impact on your search rankings because Google doesn't necessarily want to send the user to a website that they know has been down, because it provides the user with a poor user experience.

Google does make allowances for websites that are sporadically having downtime, so Googlebot will visit again 24 hours later so and see if the site is accessible."

That said, what should you show Google?

http://yoast.com/http-503-site-maintenance-seo/

According to Yoast, you should not show a 200 (ok) or 404 (file not found), but a 503 code on all pages with a retry-after header to Google.

The 503 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) tells Google "The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.:

The retry after tells Google when to come back.  You should set this to a time that is generous to allow you plenty of time to get everything back up and running.

Another point from Yoast that he links to https://plus.google.com/+PierreFar/posts/Gas8vjZ5fmB - if the robots.txt file shows a 503 then Google will stop wasting time crawling all your pages (and wasting time) until it sees a 200 back on your robots.txt file.  So it is key that you get the 503 and retry after properly on the robots.txt

Cheers!

Title tags - put your main keywords for the page first, or near the beginning.  That helps google know what the page is about.  The number of characters varies as Google does not look at characters per se, but pixel width.  Good article by Dr P.

https://moz.com/blog/new-title-tag-guidelines-preview-tool

You just have to watch what gets cut off at a certain point.  Beyond that length the title is getting too long for readability anyway and if you need a longer title to explain a page, just put the longer one in the H1, but try and be sensible.  If the client insists on putting the company name and you are not trying to rank for the company name just do something like

Keyword and keyword is really key here because it ranks good! | Company Name

The company name is at the end and will get hidden in the serps anyway, and you have your key word(s) or phrase in at the start.

Meta description is about conversion and click through rate vs ranking.  Focus on getting the best call to action with a keyword somewhere in there first.  I would say, this could be a good place to sneak in the company name, after you get your call to action right.  Your limit is larger there (about 150-160) so you have more room before the cutoff.   I tend to worry less about keywords and think about searcher intent and see if I can match that to get them to select my page among others in the search result.  Another good article by Dr P

https://moz.com/blog/i-cant-drive-155-meta-descriptions-in-2015

Cheers!

The page you mention

http://www.tripcentral.ca/vacations-packages_mexico.html

is about Vacation Packages to Mexico.  That is the "product" you are selling and aggregating ratings on them on the page and then marking them up with schema.

You then have the item reviewed as "Mexico"

But if you look at all the individual ratings they really all for different resorts in Mexico and not single specific Mexico vacation package.  Example from your page

review [Review]:

name:Riu Santa Fe - Great Resort

datePublished: 2015-09-06

reviewBody:

Very clean resort, nice rooms food was ok a lot to choose from. Barbq by the pool was excellent. Great entertainment staff. Spent most of our time at infinity pool. Staff does an excellent job shutting down party pools early to get drunks out and back to room. They are also quick in stopping rowdiness late at night. Would go back again. Sunwing very comfortable flight and champagne toast was a bonus you don't get anywhere else.Google is normally looking for the aggregated review rating to be of a single product or location.  i.e. if you had an aggregate rating of the Riu Santa Fe resort and then all the reviews were of that hotel/resort it would all tie out as far as Google and schema is concerned.What is probably happening is that when you have only a single review, Google is seeing that as the single review for that hotel and so you are ok, and the stars show up in the SERPS.  Then you start to add the other reviews related to other hotels/resorts, your stars get dropped as you are now mixing up reviews of different locations/things and Google does not like that.I have as a general rule that when I aggregate ratings like you are doing, I show the aggregated review results to the user as it may be helpfil, but I do not mark that up in schema as that is not what the schema was intended for.https://developers.google.com/structured-data/rich-snippets/reviewsReview and rating markup should be used to provide review and/or rating information about a specific item, not about a category or a list of items. For example, “hotels in Madrid”, “summer dresses”, or “cake recipes” are not specific items. See also our structured data policies for multiple entities on the same page.Good luck!

This is similar to the question, blog on a different subdomain vs a folder.  Most SEOs would agree that putting a blog in a folder is better as any links to the blog builds the domain authority of the entire domain.  Rising tides raises all ships.

Likewise, I think it is telling that Moz rolled OSE under the main moz.com domain.  Why? I would guess (Disclaimer: this is just my guess as I do not speak for Moz) for the same reason of consolidating domain authority, but also I think it makes sense from a branding perspective.   Why would you want to spend all this time creating a tool and getting people to remember another domain name when you could be piggybacking off the fact that they already know your domain name to start with and so with any press around the new tool your main domain name is being talked about (let alone linked to).

I think in most cases a separate domain or subdomain is at the suggestion of developers to make it easier to develop on a separate server etc.  That is technical hurdle that should not drive the answer of what is best for your users and for branding.

One domain name is hard enough to remember, why make people remember another one?  Keep it simple. Reduce cognitive load.    Plus, if the new tool goes viral and is on your main domain, your main domain is going viral as well.

Unless you are trying to build a separate company with a separate brand, then you might go the separate domain route.

Probably not.  If you are going to pay $500 and get a link wheel, you will end up with a bunch of spammy/low quality sites linking to each other and to you and that will just kill you.   In theory, if all the sites were of high quality and were on related topics, sure it would help, but the time and effort and cost would not be worth it.

(offers napkin to EGOL to wipe up coffee spittle)

http://googlewebmastercentral.blogspot.com/2010/04/to-slash-or-not-to-slash.html

Rest assured that for your root URL specifically, http://example.com is equivalent to http://example.com/ and can’t be redirected even if you’re Chuck Norris.

Note the quote from John Mueller in the comments

_Lots of good advice from an older blog post that's still valid & relevant today. _

There may be some technical merit that Googlebot starts at the slashed version on the TLD, but I do not think there is any type of SEO advantage with that (if that is the case).

Well, you can move to a black or gray hat technique of link building, get results (maybe), and if you do, just have them later backfire on you when Google updates the algo and puts you back to square one.  

I would suggest continued education such as http://moz.com/academy or other related sites. There is a ton of info out there, just have to see what works for you.

Creating sub folders is better as you do not have to worry about your 20 web sites looking like some sort of link farm. Plus, you build the overall brand with the main website.  That said, you do not want 20 identical pages for each location on the main website.  You would want to have unique and original information on each location page about that location, who works there, what services do they provide, etc etc.

If you want to give the client more control, why not setup each of the location pages so that a location could login and update the information.  It would be just like you can update your Google+ Local profile, you could even setup a login etc.

That said, if you give the client control of the listing/page/website then you run into the issue that client will often do a poor job of providing good information, and/or mess up your SEO if you are trying to get those pages ranked.

I would suggest a hybrid solution where you setup the pages for each location, even interview each location and gather up the information that is needed to really make those location pages information rich.  You can then take input from that location and build your pages with that information.  If there are some small edits or updates that a location needs, you can make those updates (or not) as you would still maintain editorial and SEO control.

I have managed a site with thousands of locations and we found that use of the folders worked really well.  We actually gave users access to update location profiles, but often they would put information that was frankly, poorly written.  Throw out all the SEO points, some of these "self edited" location profiles did not make me want to visit that location as the copy was so poor.  It was not until we took more control of the content on location pages that we were able to get a good balance between original content from the locations and well written page with an eye to SEO.

The 410 is supposed to be more definitive

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

404 is "not found" vs 410 is "gone

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

10.4.11 410 Gone

The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.

The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.

That said, I had a similar issue on a site with a couple thousand pages and went with the 410, not sure it really made things disappear any faster than the 404 (that I noticed).

I just found a post from John Mueller from Google

https://productforums.google.com/forum/#!topic/webmasters/qv49s4mTwNM/discussion

"In the meantime, we do treat 410s slightly differently than 404s. In particular, when we see a 404 HTTP result code, we'll want to confirm that before dropping the URL out of our search results. Using a 410 HTTP result code can help to speed that up. In practice, the time difference is just a matter of a few days, so it's not critical to return a 410 HTTP result code for URLs that are permanently removed from your website, returning a 404 is fine for that. "

So, use the 410 as a matter of a few days you may see a difference with 30k pages.

All of that said, are you sure with a site that big you would not need to 301 some of those pages.  If you have a bunch of old news items or blog posts, would you not want to redirect them to the new URLs for those same assets?  Seems like you should be able to recover some of them - at least your top traffic pages etc.

Cheers

You want to go page to page (your second example) as much as possible.  Google prefers more of a one to one vs a many to one relationship with 301 redirects.  That said, if you have a bunch of garbage pages with garbage links with not much traffic to them, you may just want to let them 404 and die out of the index.  Take some time looking at your Analytics and you may find you can just drop those pages.

Directories are not the way to go.  Do you know anybody who uses web directories anymore?  When was the last time you saw a directory rank for something?  I think the last time I saw that occurring it was sometime in the last century.

Will this impact your site for SEO?  Hard to tell based on your overall link profile.  It may make no difference.  If you wanted to be conservative, I would take all the domains and disavow them.  You can also run the URLs through OSE and see the numbers on them.

Yes this is an issue.  All pages in pagination using rel next prev need unique titles (just like all pages on your site need unique titles).  I usually accomplish this with each title being something like

Website Name Article Archives - Page $

or

Shoe Inventory - Page $

Where $ is whatever page of the pagination the person is on.

If you do have duplicate titles due to pagination (or otherwise), then you will start to see this show up as errors in your Search Console reports.

Two parts

1) If you link to two different URLs

http://youngepilepsy.org.uk/news-and-events/events

http://youngepilepsy.org.uk/news-and-events/events/

the two above would classify as that (with and without the slash are two different URLs)

and

2) if your server shows a 200 response on both of those URLs and shows the same content for those URLs

Then yes, you have a duplicate issue.

You need to

1) Make sure you keep consistent with how you link to URLs (with or without the slashes).

Decide on a standard, I personally like ending in slashes if this is an index page as this helps with reporting in places like Google Analytics where they are looking at your directory structure for reports.

If you never end in a slash

http://youngepilepsy.org.uk/news-and-events/events

and

http://youngepilepsy.org.uk/news-and-events/events/article-xyz

these two pages would be put into two different "folders" in your report for Google Analytics. I went round and round with the developers on this and had to show them the reports in GA to show why.

I also think we have had the standard that / being the index page for years now and then you have all the pages within it.  I know with modern CMSs there may not be any folders and these are all actually "routes", but as a mental organizational construct (and in the reporting example above) I think most people (who are not programmers) think that way.

That said, I currently help run a site that has no trailing slashes, and I am living with it, again, being consistent is the most important.  You will see many wall known SEO sites go sans slashes, so either way will work.

and

2) Then 301 redirect the "non standard" to the "standard" version (say the non slashed version to the slash version) so that you can clean up any other confusion that may be out there.

Cheers!

Thanks Jay. If I look on the backlinks side, they all seem to have the same subdomain in some form or another.  You would just need to setup the regex in Screaming Frog to look for just that keyword in the subdomain so it should match all the variants of it.

That said, ignore everything I just posted.  I was thinking earlier, "Surely there is scraper software out there that does this already."  I did not take the time to look.  Your mention of Scrapebox reminded me of that.

Scrapebox has a separate addon that does this

http://www.scrapebox.com/anchor-text-checker

The ScrapeBox Anchor Text Checker allows you to enter your domain and then load a list of URL’s that contain your backlink. It will scan all the URL’s containing your link and extract the anchor text used by the websites that link to you.

One key point on using robots.txt vs the meta tag noindex. It is not that the noindex meta tag is "superior" they just work differently.

If you use robots.txt - it will stop the spider from visiting that page, but it will not remove the page from the index.  Also, if you have a page in robots.txt and on that page have a 301 redirect, or a canonical or a meta noindex Google will not see the page (due to the robots.txt directive) and then not be able to act on the 301 or canonical or the meta noindex.

A meta noindex, because the spider crawls the page, will not only tell Google not to visit the page anymore, but also tells Google to remove the page from the index.  This is key if you want the pages removed from the Google index.

The rule of thumb I use is that

1. If you have a page that is not in the Google index and you want to keep it out of the index put that file in robots.txt.

2. If you have a page that is in the Google index and you want it removed, then use the noindex meta tag, do not put it into the robots.txt for reasons mentioned above.  Over time, once the pages are removed (and this may take a while depending on how often the page is cralwed) then you can put into robots.txt for good measure.

Just to clarify what is happening here, I looked at your examples links and here is what I see.

Your website has a home page (e.g. homepage.com) and site wide links in navigation etc to various categories such as

http://www.website.com/category-keyword1/

http://www.website.com/category-keyword2/

http://www.website.com/category-keyword3/

As I look at these what I will call "original" category pages, they have canonical links that link to the following pages (note I do not see this on any of your product pages or other pages on the site)

<link rel="canonical" href="http: website.com="" category-keyword2="" limit:9999"=""></link rel="canonical" href="http:>

<link rel="canonical" href="http: website.com="" category-keyword3="" limit:9999"=""></link rel="canonical" href="http:>

The URLs with the limit:9999 also show a 200 if you visit them, are a duplicate page and canonical to themselves.

This is not good.  What you are telling Google is that for each of your "original" category pages that you link to extensively with your internal link structure, that the actual (aka canonical) page is the URL with the limit:9999.

I would say that you did not need the canonical to start with, but now that it is there, here is how you fix it.

1. on all the original category pages (i.e. http://www.website.com/category-keyword1/) you need to add a canonical to self.  Just update the canonical tag and remove the "limit:9999"    There is somewhere in your CMS that is doing this, you may need a dev to help.  You have to absolutely do this.

2. on all the limit:9999 pages you have 4 possible options that you can do.  I put these in order of preference with option a being your best approach, option b your second best, and so on.  Therefore, if you cannot do option a, then try option b, and so on.

a) 301 redirect the limit:9999 pages to the original category pages

b) set the canonical on the limit:9999 pages to the original category pages

c) 404 the limit:9999 pages

d) block the limit:9999 pages in robots.txt, but be careful that you do not block the original pages.  Search Console has a great robots.txt testing tool for figuring this out.

Good luck!