Hello there,

My Uncle Dan would be upset if I did not correct you in stating that FTO for Fair Trade Organic is actually an acronym and not an abbreviation.  Uncle Dan also got mad when I used to talk about my GPS system, but that is another story.

There is an acronym HTML tag http://www.w3schools.com/tags/tag_acronym.asp but I am unaware that Google actively uses it.  I would answer your question as follows.

1. Is there search volume for the acronym and when you search for that acronym, what type of pages does Google show?  In other words are people searching for it and does Google know what it means.  When I search FTO https://www.google.com/search?q=FTO I get a pages related to the FTO gene http://en.wikipedia.org/wiki/FTO_gene that is related to obesity and also Fresh Touring Origination a sports coupe from Mitsubishi

I tried "FTO vegetables" but I got instructions on how to make lacto fermented vegetables - I could not find FTO on the page with the instructions though.  Results 5 and 6 looked to have to do with fair trade vegetables.  I Googled "FTO food" and got sites for "Fresh to Order Food" and "Food Truck Outfitters Atlanta"

My point is, if most people don't use FTO to represent Fair Trade Organic, then Google probably will not, but it still may understand it in the context of use with other words.  It may be that FTO is searched a bunch, but it may not be the searches you want.

2. Based on my 30 second assessment above, you may want to consider using the acronym in combination with the words Fair Trade Organic and that would work.  You need some variety of the words on the page.  That goes without saying.  I would not though, use it as the primary words in place like your title tag, h1 etc.  Makes more sense in the body of the text on the page.

Specifically, "would it provide a weaker result" ? It depends.  I would say for FTO searches, you would probably not show up as Google potentially does not associate FTO with Free Trade Organic.  For "Free Trade Organic" (full keyword) related searches, I would use it, but not as much as other keywords that are probably searched more often and are more relevant in the results as you need to vary up your keywords anyway.

Hope this helps!

Question - why move to the .com?  If you are a non-profit, you want to stay .org and just redirect the .com to your .org.

If you are moving to the .com, it would be like any other domain name move.  The key, you need to really plan your move and make sure you have your 301 redirects in place that is specific as possible for all of your old pages pointing to new pages.  In other words, don't redirect everything to your new home page.  Ideally, your redirects should be 1 to 1.  Old page A on .org redirects to New page A on .com.  Old page B on .org redirects to New page B on .com.  Rinse repeat for as many pages as you have.  Yes, it is tedious, but yes worth it if you do want to retain your traffic and rankings.  The more work you do prior to the switch the better.

I would advise you to read everything about the Moz migration from SEOMoz

http://moz.com/blog/domain-migration-lessons

http://moz.com/webinars/domain-migrations-lessons-from-the-moz-transition

http://moz.com/rand/10-traffic-graphs-seomoz-moz-domain-migration/

Also, lots of Domain Name Transfer - Site Transfer Type Checklists

http://moz.com/blog/achieving-an-seo-friendly-domain-migration-the-infographic

http://www.lunametrics.com/blog/2013/04/29/big-content-site-migration-tips/

Good luck!

I would say make sure that your new sitemap has all the latest URLs.  The reason people say that you should have old URLs in the sitemap is so that Google can quickly crawl the old URLs to find the 301s to the new URLs.

I am not convinced that this helps.  Why?

Google already has all your old URLs in its systems.  You would be shocked how far back Google has data on your site with old URLs.  I have a site that is over 10 years old and I still see URL structures referenced in Google from 7 years ago that have a 301 in place.  Why is this?

Google will assume that, "Well, I know that this URL is a 301 or 404, but I am going to crawl it every once in a while just to make sure the webmaster did not do this by mistake."   You can notice this in Search Console error or link reports when you setup 301s or 404s, they may stay in there for months and even come back once they fall out of the error list.  I had an occurrence where I had some old URLs showing up in the SERPs and various Search Console reports for a site for 2 years following proper 301 setups.  Why was this happening?

This is a large site and we still had some old content still linking to the old URLs.  The solution was to delete the links in that old content and setup a canonical to self on all the pages to help give a definitive directive to Google.  Google then finally replaced the old URLs with the new URLs in the SERPs and in the Search Console reports.  The point here being that previously our site was giving signals (links) that told Google that some of the old URLs were still valid and Google was giving us the benefit of the doubt.

If you want to have the new URLs seen by Google, show them in your sitemap.   Google already has all the old URLs and will check them and find the 301s and fix everything.  I would also recommend the canonical to self on the new pages.  Don't give any signals to Google that your old URLs are still valid by linking to them in any way, especially your sitemap.  I would even go so far as to reach out to any important sites that link to old URLs to ask for an updated link to your site.

As I mentioned above, I do not think there is an "advantage" of getting the new URLs indexed quicker by putting old URLs in the sitemap that 301 to the new URLs.  Just watch your Google Search Console crawl stats.  Once you do a major overhaul, you will see Google really crawl your site like crazy and they will update things pretty quick.   Putting the old URLs in the sitemap is a conflicting signal in that process and has the potential to slow Google down IMHO.

Just to be clear on what Logan said. You have to allow Google to crawl your site by opening up your robots.txt to Google so it can see your noindex directive that is on each of the pages. Otherwise Google will never "see" the noindex directive on your pages.

Likewise, on sitemap.xml.  If you are not allowing Google to crawl the sitemap (because you are blocking it with robots.txt) then Google will not read the sitemap, find all your pages that have the noindex directive on them and then remove those pages from the index.

A great article is here

https://support.google.com/webmasters/answer/93710?hl=en&ref_topic=4598466

From the mouth of Google "Important! For the noindex meta tag to be effective, the page must not be blocked by a robots.txt file. If the page is blocked by a robots.txt file, the crawler will never see the noindex tag, and the page can still appear in search results, for example if other pages link to it."

The other point that logan makes is that Google might list your site if there are enough sites linking to it. The steps above should take care of this, as you are deindexing the page, but here is what I am thinking he is referencing

https://www.youtube.com/watch?v=KBdEwpRQRD0

Google will include a site that is blocked in robots.txt if enough pages link to it, even if they have not crawled the url.

You can go into Search Console and find all the links that they say are pointing to your site. You can also use tools like CognitiveSEO or Ahrefs, Majestic or Moz etc and gather up all of those sites to find links to your site and include those in a disavow file that you put into Search Console and tell Google to ignore all of those links to your site.

Secret bonus method.  Putting a noindex directive in your robots

https://www.deepcrawl.com/knowledge/best-practice/robots-txt-noindex-the-best-kept-secret-in-seo/

This allows you to manage your noindex directives in your robots.txt.  Makes it easier as you can control all your noindex directives from a central location and block whole folders at a time.  This would stop Google from crawling AND indexing pages all in one page and you can just leave the rest of the site alone and not worry about if a noindex tag should or should not be on a certain page.

Good luck!

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!

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!

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)

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.

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

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.

The keyword meta tag is alive and well, they just call it the meta title nowadays

Regex: href=("|'|)http:(?:/{1,3}|[a-z0-9%])|[a-z0-9.-]+.

This allows for your link to have the " or ' or nothing between the = and the http   If you have any other TLDs you can just keep expanding on the |

I modified this from a posting in github https://gist.github.com/gruber/8891611

You can play with tools like http://regexpal.com/ to test your regexp against example text

I assumed you would want the full URL and that was the issue you were running into.

As another solution why not just fix the https in the main navigation etc, then once you get the staging/testing site setup, run ScreamingFrog on that site and find all the 301 redirects or 404s and then use that report to find all the URLs to fix.

I would also ping ScreamingFrog - this is not the first time they have been asked this question.  They may have a better regexp and/or solution vs what I have suggested.

Howdy!

TLDR - I would estimate Google bot desktop to run at about about 980 pixels, but there is an easy way to test, just mess around with your site by adjusting the width of the browser and see if you can duplicate what you see in Google fetch and render.

http://www.w3schools.com/browsers/browsers_display.asp  97% of browsers have a width of 1024 or greater.  Therefore, if you use that minimum of 1024, your width would be appropriate for pretty much everyone. That said, you might want to go with 980 as the width to account for things like scrolling bars and the fact that most people do not browse in full screen. This is a pretty standard starting point for width.

When you use fetch and render - Google uses one of it's bots depending on the type of page https://support.google.com/webmasters/answer/6066468?hl=en

When Google talks about responsive design https://developers.google.com/webmasters/mobile-sites/mobile-seo/responsive-design it notes, "When the meta viewport element is absent, mobile browsers default to rendering the page at a desktop screen width (usually about 980px, though this varies across devices)."  In other words in some Google documentation they are giving a nod to the 980 pixels being a "standard desktop width"

Having that in mind, I would look at your site and see if you can tell if this jives.  If you have setup the page to look "normal" at greater than 980 pixels, say 1200 pixels, set your width to 1200 pixels in your browser. Then play with the width of the browser and see if you can get it to match what you see in Google fetch and render. If your site looks the same as what you see in fetch and render and your browser is at 980 pixels, then you have a confirmation of the Googlebot desktop viewport size.

You could also setup a simple page and put several images on separate rows that are 950px 980px 1000px 1200px etc wide. Run fetch and render and see what happens, but I like my first suggestion better.

Have fun!