Welcome to the Q&A Forum

Thanks for the confirmation, Dan!

As for the process of verifying the subdomain in order to remove it using Webmaster Tools - I covered that as the last point in option 2

Paul

Probably the best concrete example of why this recommendation is valuable is when using Google Analytics campaign variables to point to landing pages.

Say your regular website page is www.mysite.com/mylanding page.html. On that page, you place the canonical tag in the header pointing back at itself.

It seems redundant until you realize that in future, you might very well be linking back to that page from a social media post or banner ad using Google Analytics tracking parameters. So the page would now be indexed under the url www.mysite.com/mylanding page.htm?utm_source=facebook&utm_medium=timeline-post&utm_campaign=mycampaign.

Google would see that new URL as a completely different page due to the extra parameters, but it would still have the canonical in the header pointing back to the plain version of the page URL, you would avoid duplicate content issues and splitting of page authority.

This demonstrates how the canonical tag can help prevent future problems even if it's not essential right now.

Make sense?

Paul

Just came across a terrific resource that reminded me you'd asked about further reading, Ben.

Check out BrowserDiet for a huge collection of resources about tuning front-end performance of websites. (You'll see #6 talks about exactly your original question)

I can also recommend reading Steve Souder's two books - High Performance Websites and Even Faster Websites - both from O'Reilly. Souders is pretty much the leading specialist in this area. He's the creator of YSlow, one of the primary tools for measuring/analyzing site speed, and is now Head Performance Engineer at Google. His website is SteveSouders.com

That'll be more than enough to get you started. Lemme know if you're still hungry for more!

Paul

P.S. The report details from tests at webpagetest.org can also teach you a huge amount, and there's a forum there run by Patrick Meenan (who built webpagetest) which is just excellent. Patrick frequently answers questions personally.

DNS servers are just like any other server, Marie - they can have outages, downtime and configuration problems.If the Googlebot visited while your DNS server was burping, it might have received no response, hence the error warning. When you checked, the server may have settled down.

There are a number of best practices for good DNS hygiene, but my primary one is to monitor the uptime of your DNS the same way you do the uptime of your website. I use my paid subscription to Pingdom Tools to do this as one of my checks, but I'm sure many other uptime monitoring tools can do it as well.

The reason I monitor is that it can be a really helpful early warning system for potential upcoming severe problems (and can help explain otherwise unexplained site outages). With one client, we saw a steadily increasing number of errors over a few days (over 40 outages on the last day), leading us to change DNS hosting before things could fail completely and leave us in the lurch.

In addition, I always recommend against having the DNS hosted on the same server as the website, as would happen with cPanel DNS hosting, for example. Reason being, if you have severe prolonged server issues, you can't get at your DNS to change it quickly to somewhere else temporarily (even if just to host an explanatory error message)

I also like to ensure the DNS is hosted somewhere with good geographic redundancy so even if one nameserver goes out, there are still multiple backups to keep things rolling. No matter how good your website's uptime is, if your DNS dies, you're still off line.

My guess is the DNS server was having temporary issues that resolved by the time you checked it. I'd want to be sure that wasn't happening on a regular basis. (relying on Google to report issues isn't nearly accurate or timely enough),

As far as the robots.txt - do you have uptime monitoring on that site? I can't count the number of new clients who thought things were fine with their website, when in fact they were having constant short outages that went unnoticed as they weren't on their own site constantly enough to catch it. I always recommend a system that checks at 1-minute intervals for just this reason. If you don't have independent verification that the site was fully up, you can't really discount the WMT warnings safely.

Lemme know if you want more info on uptime monitoring services & methods.

Paul

Marking some of the 350 links in his navigation menus isn't going to help anything, Paul. You may be thinking of the situation a couple of years ago where nofollowing links would "save" some of the page's authority to be passed to the remaining links instead, but that hasn't been the case for some time.

In general, the only real reason to nofollow links is to mark them as untrustworthy (as in the case of blog comments) or as paid links which should not pass rank in keeping with Google guidelines.

If there are 350 links in the menus, the site a usability problem, as much as an SEO problem. Except in unusual circumstances, no site visitor is going to benefit from being confronted with 350 links in a page's navigation. The solution is to fix the problem by re-architecting the menus, not by trying to slap an "SEO Bandaid" on the mess. (Especial since, in this case, adding nofollow isn't going to help any anyway.)

As far as the news headline posts, there are a couple things I'd want to know before making a decision:

• Do any of the posts have incoming links pointing to them?
• Do the headline posts make up a large percentage of the total number of pages on the site?
• Are the posts essentially worthless to the visitor now that the news they mention is in the past?

If they don't have many incoming links and aren't really of any value to the visitor anymore, I'd be tempted to 301-redirect them to the primary News category page if there is one. Otherwise (and especially if they make up more than 15-20% of the site's total pages) I'd delete them and allow them to 404 - also making sure they were removed from the site's sitemap (both html and xml.)

Does that help?

~Another Paul

it's almost never a good idea to use Google UTM tagged URLs internally, Cyto. Doing so really screws up your analytics for a number of reasons. (not to mention triggering the warning you're seeing)

if you need to track activity on internal links, the correct way to do it is with event tracking. In addition, often the In-Page Analytics section of the Content area in Google Analytics can be useful as well.

Paul

There is really no reason to block the robots.txt file from human users, Jazy. They'll never see it unless they actively go looking for it, and even if they do, it's just directives for where you want the search crawlers to go and where you want them to stay away from.

The only thing a human user will learn from this, is what sections of your site you consider to be nonessential to a search crawler. Even without the robots file, if they were really interested in this information, they could acquire it in other ways.

If you're trying to use your robots.txt file to block information about pages on your website you want to keep private or you don't want anyone to know about, doing it in the robots.txt file is the wrong place anyway. (That's done in .htaccess, which should be blocked from human readers.)

There's enough complexity to managing a website, there's no reason to add more by trying to block your robots file from human users.

Hope that helps?

Paul

Authorship can't be added to lists of posts, Samuel. It can only be added to individual posts themselves. You're not claiming authorship of sections of your site, just individual pages.

Paul

The version with URL entities you posted is almost right, Seamus, but there's a a weird combination of entities around the "hyphen surrounded by two underscores". For some reason, this is showing as %E2%80%93 when it should just be a - (There's no need to encode a hyphen as it's a standard URL character)

Try this as the source URL, with the redirect set as NOT a regular expression:

/blog/Inside_Flowers/post/Online_Marketing_for_Florists_Part_1-_A_Website_You_Won%27t_Regret/

I've tested that and it's working on my test install. If it doesn't work for you, there may be an encoding issue on your Windows server that's different from what I see on Linux/Apache.

Lemme know if that works?

Paul

P.S. Here's the Source URL for the second example used in the WordPress Forum post:

/_blog/Inside_Flowers/post/Valentine%27s_Day_Statistics_2013/

I would agree that H1s are stronger than

tags for SEO, but they're still pretty minor on-page indications.

Of much greater impact would be to better-optimize the meta-title for the page, which is one of the strongest on-page SEO factors. Right now it's just the company name "Uniko Manufacturing Limited"  Much better would be "Uniko Manufacturing Limited - Wholesale Sign and Display Industry Supply" or something similar.

Also, the page has no meta-description, which could severely handicap it when it does appear in search results. The meta-description does not help with ranking, but it's like a mini-ad for the page right in the search results to all ow you try to convince a searcher to click on your page instead of someone else's.

Better to focus on the highest impact optimizations first, rather than just the easiest.

Hope that makes sense?

Paul

Just to be clear, Laura - you say "...URL stayed the same".

By this, do you mean that the domain name stayed the same? Or that the actual URL of every single page on the site stayed the same? Meaning that the file names if the new pages are identical to the original ones, including their extensions? This is a critical piece of information.

If the URLs of the actual individual pages have changed, you need to have written 301-redirects for every old page to the new URLs in order to keep the value of your old incoming links. If the actual page URLs have changed and no redirects were done, you will be seeing a massive increase in 404 errors in your Webmaster Tools as well as in your Analytics.

If your individual page URLs have changed, you'll also need to make certain you've created and submitted a new xml sitemap. (But only after you've had the 301-redirects in place for a few days.)

Assuming at least your domain name has stayed the same, as you indicated, there's no way to do a Webmaster Tools change of address as the address hasn't actually changed.

Can you let us know if the actual page URLs all stayed the same?

Paul

If you just changed the robots.txt file yesterday, my guess is you're going to have to be patient while the site gets recrawled, Erin. Any of the pages that are in the index and were cached before yesterday's robots update will still include the directive not to include the metadescription (since that's the condition they were under when they were cached.)

I suspect the pages you're seeing with metadescriptions were crawled since the robots update. Are you seeing the same page change whether it shows metadescription or not?

As far as old pages showing in the SERPs, again they'll all have to be crawled before the 301 redirects can be discovered and the SEs can begin to understand they should be dropped. (Even then it can take days to weeks for the originals to drop out.)

Another very effective way to help get the new site indexed faster is to attract some good-quality new links to the new pages. Social Media can be especially effective for this, Google+ in particular.

Paul

Vineera, I think you're running into a common problem with the canonical notices that SEOMoz supplies in your report.

They do a TERRIBLE of explaining that things listed in the Notices section DO NOT mean that there is any problem with those items. It simply means the crawler has detected those features on your site, and that you should double-check to ensure they are implemented the way you want them. It doe NOT necessarily mean there is any problem. If you read the tiny print, the notices section description is: "Notices are interesting facts about your pages we found while crawling." So... interesting facts, not problems.

As Takeshi mentions, your canonical tags are implemented properly so you can ignore the notice.

Hope that helps;

Paul

Irving's exactly right here. External ranking factors could well be responsible for how the page is doing.

HOWEVER! If your page is ranking an F for on-page optimization, it means you are probably wasting some of the power of those off-page factors. This may not be an issue at the moment, but remember - your competitors are continually working to improve their pages that are competing with yours. So you should be using everything in your arsenal to make your pages harder for the competition to beat.

Fixing your on-page may not improve your already top rank, but will almost certainly help you keep that top ranking longer in the face of increased competition.

Paul

The SEOMoz crawler has absolutely no way of knowing what directives you have entered in Webmaster Tools, Brad, That info is only available to Google. (Which is one reason why using only that approach is not optimal; as it won't help your rankings with other search engines.)

Hope that makes sense?

Paul

What Chad means, Ian, is that you have to set up two separate GWT sites. One  for yoursite.com and a separate one for www.yoursite.com.

When on the Webmaster Tools dashboard, you'll need to click the big red Add Site button on the right to add a new site to your GWT account - create it using the version of the site that's different from the first one you created. The new site can be verified the same way the original was, using your Analytics accounts.

One the second site is set up, set the preferred domain in both sites to the same version.

The quirk is that GWT considers ALL subdomains to be SEPARATE sites, and the www version of a website is technically a subdomain.

Hope that helps?

Paul

You're going to need to escape the unusual characters in the URL in order to redirect them, Teddi.

When writing redirects, characters like < and > have special meaning as Regular Expression characters, so your server is trying to process those characters as their special regex functions, instead of just being plain old characters.

The way to turn them back into regular old characters is to place a "****" in front of the special characters.

So... the URL you are trying to redirect should be written as

www.example.co.uk/blue<u>berry_pie.htm</u>

Try that & let me know if it solves your problem.

Paul

It looks to me like you need to increase the size of the images, Rahul. The images' dimensions are smaller than the way they are being rendered in the slider, which means the slider is having to up-size them to display. Up-sizing an image like that always makes it more blurry as data must be interpolated. (Doing this up-sizing in an image editor like PhotoShop will always be higher quality, but even then some blur is inevitable).

Best to redo the images from their originals at the size the slider is actually using them.

Paul

NOTE! Image resolution has nothing to do with how images will display on the web. Image dimensions (height and width in pixels) are the only thing that matters.

Actually, I'd say your sidebar is already doing what I'd recommended, Mark. The content of that sidebar changes according to what topic the visitor has clicked on, so I would say it satisfies the conditional requirements very well. The fact the article links in the sidebar also change according to the topic of the page is great! (and even better that the article links disappear altogether if there isn't something relevant - nicely done.)

As far as the footer's concerned, I'd be tempted to get the About Us, and Contact links more visibility in the primary nav - these are more usability than straight architecture concerns, but many first-time visitors may want to get an idea who they'd be dealing with, but wouldn't notice the small, light links in the footer. If you are able to find time to expand your blog posting, I'd suggest featuring it higher up as well. Honestly, you have an interesting (and long!) history and I'd be tempted to feature that aspect more.

There are certainly still some conversion optimization opportunities, and I suspect some Local SEO work could also be beneficial, but in general I'd say the link architecture is quite good.

Hope that addresses what you were asking?

Paul

It would take a helluva lot of .htaccess rules to noticeably slow down a site, HOP. (We're talking many hundreds at least, if not more.)

The 301 redirect is a vastly stronger signal to the search engines than the canonical - which even Google says is treated as a "suggestion" not a directive.

The other huge benefit of the 301 is it standardises the URL all visitors will see in their address bar, so when they copy/paste to create a link (for example) they're always getting the canonical version.

Even though it's now considered that a 301 doesn't lose much juice (at least in Google, no word from Bing), I still much prefer that as many of my visitors are linking directly to the canonical version as possible. This is vastly more likely with the 301 consolidating the address that is visible.

So to me, using the 301 is essential. Adding the canonical is proactive to deal with other possibilities like unexpected variables getting added by outside sources for example, or even just Analytics utm tracking tags.

Make sense?

Paul