Welcome to the Q&A Forum

Canonical tag isn't likely to have the effect you want here. Search engines expect (require) that conicalised pages be essentially identical to each other or they will likely ignore the canonical "suggestion". Identical meaning essentially word for word, except for perhaps word order, like on parameter-sorted product category p[ages.

In my experience, EGOL's solution is vastly superior. Create a permanent page for each, then find all the old related blog posts and redirect them to the permanent page to harness whatever authority those pages have for the new one. That way all further authority to the same page year after year, instead of being diffused amongst many weak separate pages.

Paul

You'll need to go in to your site on the server via ftp and remove the old version of the plugin manually before updating, Erik.

This error is often caused by misconfiguration of the permissions on the plugin folders on the server.

Paul

First, to be clear, the Webmaster Tools notifications are just that. Google isn't indicating any kind of a problem, Erik. It's just declaring what it has found in the site's robot.txt file.

There's no way to give a definitive answer without seeing the actual website structure, but in general, it is VERY common and good practice to no-index the categories and tags on CMS-based websites. Usually, you want some form of the archives to be indexed, but it's usually the individual pages that are most important. (e.g. not date-based archives.)

The problem with allowing all of these to be indexed is that to a search engine, they will all look like duplicate content of other pages on the website. This will cause the search engine crawler to have to work much harder to find all the content on your website, and ad a result may quit part way though.

In addition,much of the content it finds it will consider to be duplicative of other pages on the website, and therefore will have a hard time knowing which version is actually the most valuable result to return. And as a result will split the authority of each of the pages, making them MUCH harder to rank.

This is a standard challenge of any CMS based website, because they display the same content organized by what are referred to as different taxonomies (different ways of categorizing or linking the same information).

Again, without seeing the actual site I can't say for sure, but short answer is that those three directives are very common for CMS- based websites and are very likely correct.

Hope that helps?

Paul

While a good solution if it were possible, unfortunately ESPs like Constant Contact don't give you any way to alter the content of the of their pages. And canonical tags must be in the or they'll be ignored.

Wp-includes doesn't include any user content, William. The wp-content folder is where all user-uploaded images, pdfs etc are stored, so removing wp-includes from the robots.txt won' t have any effect on whether posts/pages are indexing or not.

But even if such content were in that blocked directory, posts and pages are in the database and are output from their respective pseudo index pages, none of which are ni the /wp-includes directory.

I'm just on my out the door, Eric, but if you want to PM me a few example URLs/pages, I'd be happy to have a look. Or of course you could post them publicly here for others to give you a hand, if you're comfortable with that. It's pretty hard to address problems like this without being able to research the actual pages.

Paul

I'm just cynical enough to suspect this may be a byproduct of Google Webmaster Tools recent inbound link meltdown. Huge numbers of GWT users are reporting that their inbound link reports have basically lost most of their links.

What if, in dealing with the problem, Google has gone back to an older version of the links database, which might recover more of the recent links, but also pull back a whack of  those links it already discounted?

This is pure speculation on my part, but there's been so much volatility on Google's link reporting recently that I can't say I trust the data as far as I can toss it at the moment.

Have you tired a similar comparison to the data shown in Bing Webmaster Tools?

I'm sure I read of others encountering what you're talking about recently. Will see if I can find the references in case they found anything.

Paul

You actually have two issues, Aidan, but the one the SEOMoz crawl is reporting here is not what folks have mentioned so far.

The warning is telling you that the code of your webpage contains two instances of the meta-title tag. The meta title is found between the <title>tags and only shows in the code, not the rendered version of your page. In your case, there's a version of the meta-title tag on line 84, and another on line 97 in the header section near the top of your page. All of your pages have this double-title problem.</p> <p>If you have two title tags, the search engines won't know which one to use. As a result of this confusion, the search engine is actually discarding your page titles and making up one of its own based on navigation - never as good as trying to get it to display the ones you've actually designed.</p> <p>On closer inspection, your pages have a significant configuration problem because they actually have two (nested) <head> sections. Something is adding a second <head> section that contains the extra unwanted title tag. Perhaps there's a plugin doing this? (See attached image of source code - the circled area is code that should not be there)</p> <p>The second problem, as shiftins and Joel point out , is that if you have multiple pages targeting such similar terms,  the search engines will likely be unable to tell which is the most important (authoritative) page. They will essentially split the ranking power for those terms between the two pages, making each rank lower than one would by itself.</p> <p>Paul</p> <br> <br> <a download="6vwja" class="imported-anchor-tag" href="http://imgur.com/6vwja" target="_blank">6vwja</a></title>

Colin, if you just copy and pasted the code Daniel provided, there is a typo in his spelling of your domain name - note the extra "s" at the end of the word "Nile".

If this is the code you're using, the redirect can't work because there is no such page to redirect to (the not redirecting to any url part of the error).

Did you include the typo in the .htaccess entry you created?

Paul

Quite a few people have been noticing this over the last several weeks, KC.

It was mentioned a week ago on Search Engine Roundtable and I was discussing it with another Calgary SEO who had noticed it over 3 weeks ago.

There have been a number of suggestions about when Google's doing this kind of title tag re-writing, but no sooner does someone come up with a theory, but somebody else shows proof that contradicts it. E.g. for a while it was thought the re-writing was occurring for brand searches, especially where the brand name was split off at the end of the title by a separator like a hyphen or a pipe pipe. But your example shows for a keyword search, rather than brand.

It really looks to me that Google is experimenting with this. I've seen it come and go, and it is in no way consistent at this point, which is why nobody seems to have been able to nail down a specific set of circumstances in which it occurs.

Sorry this doesn't really give you any actionable info. Just wanted you to know that others have been seeing it recently as well.

Paul

P.S. And hi from just down the highway in Canmore!

I'm with Anthony that this is a perfect example of where there's no reason to guess when testing can give you your visitors' answer instead of your own.

I suspect testing will show that a form on the homepage isn't going to get used much. Filling out a contact form is a fairly deep-funnel conversion. A visitor must already be pretty sure they're considering doing business with you to bother filling out the form. Or they've looked through the site and can't find the info they're looking for.

Are they likely to make this decision based on just having seen your homepage? Not likely. Better to use that space to give a new visitor more useful info.

But that's just my opinion. Test and let your visitors tell you whether they'll use it

Paul

There are a number of issues that are likely causing indexing problems with this site, Eric, but I'm going to have to be up front with you.

The site's business model is so completely against the search engines' terms of service, and is contributing to the low opinion so many in the public have of SEO, that regretfully I must decline to provide any further help with this particular site.

This is my own judgement call and is not intended to reflect on you in any way.

Paul

Unfortunately, Nic, the SEOMoz tool does a really bad job of explaining that the Notices section of the on-page reports does NOT mean those areas have problems. The tool is simply informing you that those specific elements appear on your website. It is then up to you to decide whether they're appropriate or not. (The exact wording is "Notices are interesting facts about your pages we found while crawling". Pretty vague)

In the case of the canonical URLs, they're definitely a good thing and as neither you nor Oleg see any problems with them, all is fine.

As an example, that Notices section would also tell you if it found no-follow tags. If those had been added accidentally, they could be disastrous, so having the tool tell you they exist could warn you that someone had made a mistake. Or it could simply be that you put them in place on purpose. See? Judgement call.

Hope that helps;

Paul

The trick with sitespeed testing, Brett, is that you need to approximate as closely as possible the experience a real user will have.

By far the best tool for this in my experience is webpagetest.org.

It uses actual browser rendering for it's test, not a synthetic imitation. it also allows a couple of other critical customizations:

• select which browser you want to test your site with (you'll be surprised at the differences! Use you Google Analytics to tell you which browser majority of your visitors use)
• Select what sort of connection speed to test from (eg slower DSL which will also mimic phone users or faster cable connection)
• select a specific city to test from (this will have major effect - e.g. you should test from the San Jose location which is much more realistic for your Comox location than an east coast or southern US test would be)
• run a mobile-specific test
• shows both first load and repeat visit (particularly tests caching effectiveness)
• provides a waterfall view so you can exactly which elements may be causing issues

The app also provides full Google Page Speed results/recommendations and a number of other trouble-shooting tools.

GTMetrix provides a number of these, but doesn't have the same flexibility/customization available, I've found. (Though it is using a Vancouver-based server for your test from here (Alberta) which is useful.)

Note that you will get different results each time though, if you're using a real-life tool. That's due to differences in network load and latency and even different load on your server each time tested.

Finally, below is a screenshot demonstrating why you absolutely need to use a real-life test, not just synthetic Page Speed or YSlow scores - the site has a beautiful synthetic score yet a disastrous load time (due to server issues)

Paul

rDQjD.jpg

As Tim mentions, it's critical that you add the customization for Site Speed Sample Rate to your Analytics tag if you are going to use Analytics to assess your users' actual page speed experience on your site (which it does quite well, once it's configured).

If you don't make this customization, Analytics is only tracking 1% of page views, which makes it essentially useless as the huge variations between a few individual users will badly skew the results.

Also note that for technical reasons, this process won't track pagespeed for iPhone mobile visits.

Paul

Another vote for proactively adding canonical tags to all pages. They're a great preventive measure in case someone else links with unusual parameters.

Also, Google is "supposed" to understand the UTM tags and ignore them, but we've all seen cases where Google's actual processes don't work quite like they're supposed to. (I've seen plenty of utm-tagged URLs indexed in Google)

(Plus, there's even less guarantee that other search engines would discount them and avoid dupe content. Bing et al may not be a huge traffic source on your site, but no sense throwing it away unnecessarily.)

Paul

It's an old proprietary filter used to try to fix rendering in older Internet Explorer browsers (IE 6 and earlier) that didn't properly support transparency in .png images.

Its use is harmful for page optimisation because it blocks rendering for the rest of the page while it is processing for each element.

Since most of us no longer worry about supporting IE 6 and older in our site designs, it's not worth using at the expense of all our modern browser users.

Paul

This is a really common problem on shared Windows IIS-based hosting, Brian.

In addition to the web.config method Oleg mentions, there's another method if it's only for a few specific pages.

This method involves actually having a "placeholder" page on the server at the old URL. You then add a script to provide the 301 redirect. (Or just replace the content of the origianl page, if it's still on the server.)

For example:

On ASP.net you would create the page oldpagename.aspx and its content would be:

On ASP you'd create the placeholder oldpagename.asp and its content would be:

<%@ Language=VBScript %>
<%
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "www.mydomain.com/newpagename.aspx"
%>

Obviously this method doesn't scale as easily as the web.config method, but it's generally easier if you're just dealing with a few pages every once in a while.

Paul

You can actually get the best of both worlds using the Redirection plugin Iain mentions, Himanshu. The plugin can be configured so that the redirects you create within it get written to the .htaccess file.

Having the redirects in the .htaccess file is preferred, because the .htaccess is processed faster and with lower load by your server than the redirects within WordPress. This is obviously much more important if you have a large number or redirects to write, as opposed to a dozen or so to deal with a few changed pages.

Paul

What is the specific redirect you're looking at, Brett? In some cases, redirects are essential to the way certain functionality works. This can be especially true of security plugins. In which case a judgement call has to be made whether the security feature is more important than the tiny increase in site speed from removing it.

Paul

And of course having different "C blocks" would in no way be enough to separate the sites in the eyes of the search engines.

Just for starters, you'd also need to ensure none of the following are shared between any of the sites:

• Analytics accounts, whether Google or other 3rd parties
• Google and Bing Webmaster Tools accounts
• Adwords/Adsense accounts (or probably any other ad networks)
• domain registrar accounts

So as Allan says, totally not worth it for the slight potential gain. There's no way they can be considered "natural" so only use them if they're useful to actually drive human traffic ("hmm.. nice-looking site, I wonder who built it") and then nofollow as Alan recommends.