Welcome to the Q&A Forum

Your uploads directory is viewable. I would configure the hosting to disallow browsing directories.

Because WordPress creates a directory for each month you have two dozen pages being indexed by Google that show nothing but filenames ending with the .png extension. This is most likely where the keyword in Webmaster tools is coming from.

Due to the extraneous text at the bottom of your question I am answering each question with the subject of the question prepended to the answer in parentheses. So in answer to your questions:

1. (tools available) Moz Analytics, Followerwonk, Open Site Explorer, Fresh Web Explorer, Rank Tracker, Keyword Analysis (including keyword difficulty), On-Page Grader.

2. (crawl entire site) Yes, add your site as a campaign and Moz will crawl your site and inform you of any problems and factors affecting your rank. It will also track changes over time without manual intervention.

3. (10 campaigns) Yes, each domain is a separate campaign.

4. (subdomains) This is configurable. You can set in campaign settings whether to track only this subdomain or all subdomains or even just a specific sub-folder.

5. (keywords) The number of keywords relates to how many keywords can be tracked in your account as a whole across all of your campaigns. 750 over 10 campaigns gives you 75 keywords per campaign. The rank of your site's pages is tracked for each keyword, pages are graded for their ranking ability against specific keywords and you can check the rank of any page for any keyword you are tracking.

6. (social accounts) You can track the performance of your social media accounts by connecting them with Moz Analytics. You can also track your competitors accounts to measure your performance against competitors in some aspects such as the level of interaction (comments and shares).

7. (branded reports) Branded reports allow you to export reports on your data with your own branding, a useful feature for agencies and consultants.

I am a Moz Pro subscriber and highly recommend it, Moz Analytics and the various other tools are extremely useful.

In 2011 Matt Cutts advised that Google does limit on redirect chains - he indicated the Googlebot won't follow more than around 3 or 4. No limit on the total number of single-level 301s.

In your specific situation I would redirect both the original and the first replacement to the new replacement so that users and bots can reach the new page in a single redirect hop.

Once upon a time it was possibly a good use of the meta description to include some salient structured data but today we have a proper way of marking up structured data. The meta description is best used for compelling, relevant copy to attract the user to click through to your site as the meta description is your one best hope of affecting what is shown to the user in the SERPs.

Search engines haven't shown any inclination to parse the meta description and I doubt they would do so in future. Structured data belongs in the document itself, marked up accordingly.

It is absolutely fine to reach out and gently ask for a correction, in my opinion. I have done it myself several times recently and all individuals contacted were quite happy to oblige me. The important thing is to be sincere and genuine in your message and remember that the person on the other end is likely busy so keep your message to the point and give precise instructions to minimise any need for back-and-forth email clarifications. Be patient - but chase after a month or so, if necessary - and do follow up to thank them for correcting once they have done so.

Some years ago people used to make this claim about W3C validation badges too. A badge is a badge is a badge. It really is unlikely to affect your search rankings one way or another.

Google only shows rich snippets when it thinks it will be useful to the searcher.

As you have said you have had some issues with maintenance, check the structured data against Google's structured data testing tool. However it is more likely that Google isn't showing the rich snippets because it believes your page quality to be low or that the structured data is not relevant to the user's query.

The cache info box shown in Google's cached pages is actually present but is being hidden by the website's design, specifically the div element with the classes "wsb-canvas body".

I think it is important to distinguish the purpose of the automated validation services offered by Google and Yandex, which is to ensure that the properties utilized by the respective search engine are present, and the actual schema.org structured data initiative which doesn't place many requirements on publishers.

With that in mind when Yandex states that the address and telephone properties are required for http://schema.org/Organization, it doesn't mean they are required by schema.org but rather that they are required by Yandex. Google's Structured Data Testing Tool doesn't state that these are required because for Google's purposes they are not.

So both are correct but for purposes of ensuring your structured data is showing up you do need to test in all of the relevant tools. For less mission-critical structured data it is OK just to follow the Schema.org documentation and wait for the providers to implement support.

Implementing SSL should be straightforward for the most part

You need to ensure that links around your site (including canonical links) are updated to use HTTPS (so https://example.com/link as opposed to http://example.com/link where example.com is your domain name). If you are already using a protocol-less linking pattern (//example.com/link) you don't need to update the links.

You can also configure your web server to only serve HTTPS. If your web server is Apache you can do this with the SSLRequireSSL directive.

 <code><location>SSLRequireSSL</location></code> 

HTTPS also causes a significant slow-down as the browser and the server negotiate a secure connection. If your site has already been optimized for speed it should not cause a problem but if in doubt revisit that process and ensure that you are getting the best possible speed for your visitors.

The article by Cyrus has a great checklist to double check everything.

That looks to be a good solution. Behind the scenes the plugin will be adding "Options -Indexes" to your .htaccess file, which you could do directly and skip the need for a plugin if you so wish.

I am glad I was able to help you.

I would suggest using the Padauk font from SIL instead. This uses the Unicode standard and you should be able to use CSS font embedding to maximise the support for other browsers.

Google should be able to understand the content as long as it is encoded in a standard character set (UTF-8, for example). Even though Zawgyi is not compliant with the Unicode standard your pages should be being served with the UTF-8 character encoding so Google should be able to index the content. I don't think Google pays any attention to the font in use by the design but it is an interesting point which I haven't particularly considered before and which I had to think about carefully before posting this response.

Moz Local presently only supports the United States. I ran into this myself a while ago. Hopefully they'll get around to supporting UK and Germany soon.

Ruben, I had a look at your website and your URLs all have HTTP in them so these would need to be updated all across your site before you make the switch to HTTPS. Because you are using WordPress this should be as simple as updating the site URL to https://www.kempruge.com.

The tip by @Highland about using Firebug is excellent. This will allow you to quickly debug if there are non-HTTPS links remaining - in the WordPress theme or template, for example.

Have a look at the WordPress HTTPS documentation also.

This will depend on what slideshow plugin you are using. If you respond with that information it will be easier for someone to give you a definite answer, and I will try to do so myself.

Edit: for what it is worth, I am seeing the alt tags on your photography website.

Interesting question. The Government of Hong Kong uses standard Chinese in simplified characters on its website while the population largely speaks Cantonese which is now found in a written form frequently used online and in social settings.

I suggest you have a look at Google Trends for Hong Kong and see if the bulk of searches are being made with simplified characters or traditional characters. The demographic your website will be targeting will also be a factor.

For best results Google recommends that all the rules should be the same except the membership duration. Then combine them, yes.

There's no law that says a 404 page has to be dull and unengaging. Back in the palaeolithic era of the web if we saw a lot of hits to the 404 page in the server logs we rarely knew why (finding broken links was a lot harder in those days) so we tried to capitalize and added engaging graphics and search boxes, copy designed to improve the retention of all these poor lost souls.

Working on your 404 page can actually be a really good experience. With the tools at developers disposal today it should be super easy to work out the context of the 404 error and show something useful to the user and win them over.

All that said if you find yourself relying on this technique in 2014 it is probably a sign something has gone wrong with the site's information architecture. Restoring the category page but serving a 404 is probably a no-no - you're essentially saying "no, this doesn't exist" to automatons (user agents and search crawlers) but you are showing the user the page they were presumably looking for. Finding yourself in a situation where you are sending deceitful HTTP headers is a clear sign something is wrong.

If the pages are useful and visited, restore them and work on making them better. If they aren't useful enough then you should probably 301 to a relevant useful page. Don't worry about having too many 301s, redirecting is the technically correct thing to do in such situations and your search engine of choice can hardly penalize you for using HTTP features correctly.

I'm afraid it is the obvious. Ensure the rich snippets are relevant to the content of the page, ensure that your page is ranking for relevant queries to raise the chance of the rich snippet being shown.

When you say that you know you've had over 100 visits, how do you know this? Server logs, for instance, record hits not visits or unique visitors.

If the visitor stats in Google Analytics and Moz match - which they should - then it seems unlikely there is a problem. Remember to filter by the same period in Google Analytics as your timeframe in Moz Analytics.

I wouldn't advise a client to link out to one site so much unless it was adding significant value to the page. This kind of "list of links" page is not particularly useful to visitors who could probably have found the webmd pages anyway and it doesn't add much to the content of the website. I suspect it was created in a misguided attempt to satisfy a criterion of linking to authority sites.

The page is also titled "Saint Louis Links" but AFAIK webmd is not a St Louis company.

You need to ask "am I doing this purely for the search engines/SEO purposes?" or for the visitors. If the latter you should nearly always go ahead with it but of course optimize it for SEO. If the former you should probably drop it as you should be building for your audience, not for search engine algorithms.

Edited to answer your direct question: if links are adding value to your content you should make them followed.

This is a known problem with YouTube's safety mode filter but there is not much information about it. There is no official appeals process but you can report it on the support forum thread where one of the community volunteers, Epontius, has been helping to escalate some users false positive reports to YouTube's staff. You could report the false positive there and ask for Epontius help. Hope this helps.

410 means "Gone" and is used to indicate a resource no longer exists. If it exists use 200 (OK). If it is out-dated place a notice to that effect but still leave it as 200. Putting a noindex instruction in the robots meta element should be sufficient to remove it from the Google index, though it may take some time. Nofollow is probably not what you want to do as this will destroy any link value flowing through those pages. If it is so out-dated that it is considered valueless then it should be deleted and 410'd. A 301 redirect can be used where a new resource that substantially replaces the old resource has been created.

Not sure why you would want to keep Google's index of your site 'lean' unless you have a lot of resources competing for the same keywords and are concerned about cannibalization.

Your site is competing in a very highly competitive field. I did a check in Moz Keyword Difficulty on your example page's targeted keyword (nokia lumia 830 review) and that keyword is highly competitive. The Google India SERP for the keyword is dominated by high domain authority sites with high page authority pages.

Shawn, a quick question to open up possible avenues: did you extend the Flawless theme or use it as-is?

Michael has it right. Online Agency (onlineagency.com) build websites for travel agencies. In the URLs you gave, Patrick, you can see some sort of ID for the site (starmandstravel.com). I guess that this content.onlineagency.com subdomain is the content management system to allow the travel agencies to update their content.

Google may be interpreting lots of similar/related websites on the same infrastructure as an attempt to game its algorithms (they have the same nameservers, although different c blocks but many of the other sites built by that agency also share the same c block [..170.140]).

Try using something like LiveHTTPHeaders to view all of the HTTP requests and responses involved. You should see the request going to the redirected domain (GET domain.co.uk) and then the response such as HTTP/1.1 301 Moved Permanently followed by a new request to the new domain (GET domain2.co.uk) and the response will naturally be HTTP/1.1 200 OK because the server at the new domain has answered the request successfully.

Your question is somewhat ambiguous. "Too many requests" could mean that your website's design is pulling in a lot of resources and this, particularly with Javascript, can cause load speed issues. If it is related to this you can look to merging some of your Javascript files, loading Javascript asynchronously where advisable, look at reducing CSS bloat (stripping unused rules, etc).

"Too many requests" could also mean that the server is suffering under load. If it is this latter meaning reducing any design-related resource loading issues may actually help somewhat but the site will still not reach reasonable speeds. To resolve this you'll need to look at reducing load on the server. This can be accomplished by making use of caches where appropriate.

Use the PageSpeed extension in Chrome or Firefox to diagnose some of the problems that might be affecting your site. If you suspect server load and if you have SSH access assuming it is a *nix machine try the "uptime" utility and have a look at the load averages.