Welcome to the Q&A Forum

Hey Marie,

If it wasn't for the Panda situation, I would say you should 301 redirect the subdomain back to the main site. I've had to do that more than once (unfortunately) and a redirect has worked every time to remove the development subdomain from the search results.

However, because of the Panda flag, that may result in both the main site and the subdomain site getting flagged by Panda and thus both sites falling out of the index (which might make it even harder to regain).

Here is one thought. Is it possible to redirect a few pages on the subdomain and put a canonical on a few other pages on the subdomain? That way you could see what happens with those pages. If I were you, I would test out both options before applying to the whole site and I'd test on the most insignificant pages there are on the site (privacy policy, terms and conditions, etc.)

This is a really interesting question and I'll be anxious to hear what others have to say. Please let me know what ends up happening and how you go about fixing this.

Matthew

Hey,

You can do cross domain canonicals. Google does support that (http://www.youtube.com/watch?v=zI6L2N4A0hA) and the one time I had to use that, it did seem to help. That being said, I'm not sure if Bing supports that or not.

Hope that helps.

Are you referring to the ratio followed vs. no followed links? There are some good answers about that here.

http://www.seomoz.org/q/does-the-ratio-of-external-nofollow-links-to-external-do-follow-links-matter-in-terms-of-serps-ranking

Hi Joel,

Yes, you can use multiple h1 tags across a page. From what I've seen, it doesn't have much, if any, impact on your search performance. As for HTML5, it is completely valid to have multiple h1 tags or to structure it with an h1 per section.

All that said, I still prefer to have only one h1 tag per page. Realistically, each page can only have one heading that is the most important. However, this isn't about search or usability or programming requirements, it is just my preference because it helps me prioritize my content.

Thanks.

I guess it depends on what is the intention behind these pages? Are you attempting to get more traffic for search? Or, are these pages simply for people visiting the site? If it is more about people and not search engines, I wouldn't really worry about the duplicate content issues (provided the pages make sense to users). Adding a nofollow to the links referencing these pages (and a noindex,follow on these pages) will prevent Google from crawling unnecessary pages and indexing unnecessary pages.

I've had similar situations come up (it always seems to on large sites). Typically what I've tried to do is identify which pages have the best shot at getting activity within the search results (based on keyword research, link research, etc.). On those pages, I do everything I can to have really unique content that sets those pages apart (I'm talking bigger scale changes, as opposed to geo-targeting changes). For the other pages where there isn't such a great chance with search engines, I use the nofollow tag to prevent Google from accessing those pages. That seems to help keep the focus for SEO on the right pages.

Hey Dana,

I've had this problem with Safari being slower as well. In fact, I just checked a handful of sites in Google Analytics and Safari is almost consistently the slowest browser. One question to look into is whether or not mobile traffic on Safari is slow. For the sites I'm looking at and for the sites I've worked on in the past, the culprit is usually Safari's desktop browser. Phones are usually within normal loading parameters (by phone standards).

Unfortunately, in most cases, the sluggish performance on Safari is due to Safari's DNS prefetching. Generally, prefetching does the opposite, but apparently can slow you down in Safari. You can read more about that here. http://macs.about.com/od/MacTroubleshootingTips/qt/Troubleshooting-Safari-Slow-Page-Loads-Caused-By-Dns-Prefetching.htm and this is another good one http://computers.tutsplus.com/tutorials/how-to-fix-slow-and-non-loading-webpages-in-safari--mac-51338 (Lots more if you Google Safari prefetching.)

I do think it is worth it to try to fix it. Here's what I would do, if I were you. Feel free to PM me if you want more help...

The way you fix this is on the client's machine, at least according to those articles (and others I've found while Google'ing around just now). However, you can try these steps out on your computer (if you've got a Mac) and see if you have an improved performance in Safari. It shouldn't take that long to test, and is probably worth it given the huge loss you are seeing due to this issue.

The next question is, well, how do I do this for everybody? The answer is to ask your visitors to use Chrome! No, seriously, one that worked for me in the past, was to detect the Safari user agent and load a slightly different version of the page that required fewer requests, meaning there will be less for Safari to prefetch. For instance, you might get rid of JavaScript, images, etc. that isn't essential. Obviously, keep the core content so that the pages are basically the same (kind of like you would for mobile detection).

This is obviously much more complicated to setup as it requires adjustments to the design as well as the code structure. But, generally simpler than trying to redo your entire website.

Before you make any such changes, it might be worth running a simple test on a key landing page that gets a lot of visits from Safari. Remove what elements you can for all user agents and see if this changes anything substantially with the site speed in Safari.

I hope that helps. Thanks,
Matthew

Hi Richard,

Updating htaccess files can be tricky, especially with that risk of wrecking your site if you do something wrong. So, not a dumb question at all.

WordPress is a great way to add redirects, but if you are dealing with hundreds that can equal a lot of time.

So, if you are looking for a way to quickly build the htaccess file vs. doing everything manually in WordPress, my trick is use to a concatenation function in Excel. That way I can write hundreds of redirects at once and then copy the resulting text into the htaccess file.

The general idea is you have your old URL path in col A, the new URL (full URL) in column B, and then in column C, you'd have a formula that looks something like this (obviously line numbers might change):

="redirect 301 " & A2 & " " & B2

You could then copy column C and add that to your .htaccess file. Of course, back up the htacecss file first. The only word of caution would be to make sure you have valid paths in column A (no special characters, no full URLs, etc.).

Hope that helps.

Yep, on two different sites we did thousands of redirects at a time with no issues. In one case it was annual and the other it was quarterly but I don't see any reason monthly would be any different.

Definitely post your findings after implementation or maybe even write a YouMoz post about what you find out!

Hi,

In general, yes, duplicate content is not good and can be harmful to your site. There are many reasons why this is true, but in terms of search it can be bad because it can divide the focus.

Let's say those four pages that are duplicated on your site are really important pages. You want those pages to rank and get traffic. By having duplicate content, you are dividing the focus across multiple pages. You'll have links going to all those pages, instead of all those links going to one page (internal and external). The same is true of social shares (to whatever extent that influences search). This makes your job that much harder to optimize those pages because you are dividing the focus across all four pages when really you should put all the focus behind one page.

Obviously, there are other issues beyond search. Duplicated pages can be bad for usability and can be a sign of an architecture that needs to be re-worked.

Hope that helps.

Hey Richard,

You are really close! In column A, do a find for "http://www.global-lingo.com" and replace with nothing. That way you are left with:

A = /news/2009/12/news-internet-translations/

B = http://www.global-lingo.com/blog/

C = redirect 301 /news/2009/12/news-internet-translations/ http://www.global-lingo.com/blog/

Thanks,
Matthew

Hi,

Here is an article explaining how to do this in robots.txt:
http://sanzon.wordpress.com/2008/04/29/advanced-usage-of-robotstxt-w-querystrings/

Depending on what you are trying to do, it might also be worth investigating parameter handling in Google Webmaster Tools:
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=1235687

Thanks,
Matthew

I'd argue in favor of creating different, unique, targeted pages for each OS. That way each page for each OS can be indexed by Google/Bing and target different words, giving you more ways to attract traffic into the site. Plus, any time you route traffic differently based on user agent you open yourself up for a lot of potential problems.

Also, you might consider doing some JavaScript cookie-based detection and default people to one OS page or another, but still give users/search engines a choice to access the other OS pages (in case that detection was wrong or users are interested in another OS).

I've had issues getting images indexed as well. A few thoughts:

--> It could just take time. It has been a week since you posted, so if you are still having this problem, then clearly something isn't right.

--> Along with checking GWT, have you been searching for the image in a Google search? Sometimes GWT doesn't show the most accurate number.

--> Have you verified that your image sitemap is valid? Sometimes a simple mistake can prevent indexation. If you want to send me the link via private message, I'd be happy to take a look.

--> Obvious question, but have you checked things like robots.txt to ensure images can be accessed by Google's bots?

Hi,

First off, even with a canonical, I'd suggest you have a unique title tag if for no other reason than users. Changing the title, even slightly, can help. For my clients, I usually suggest something simple like adding ", Page #2" after the main title. Google may or may not index the page, but that way if a user bookmarks the page (or shares it), the title is different.

Second, you need more than a canonical link to correct this problem. You are dealing with a sequence, which means you need to use rel prev/next as well as the canonical. (For example: on page 2 of your jobs, the canonical would be /jobs/2, the rel prev would be /jobs, and rel next would be /jobs/3.) Treating these pages like a sequence will help explain this group of pages more effectively. And, that means...

Finally, the rel prev/next would also help those second, third, fourth, etc. pages  from falling out of Google's index and allow Google to find those jobs listed on those subsequent pages. Instead of telling Google that the subsequent pages are duplications (which is what you are saying by having a canonical referencing the main page on each subsequent page), you instead would be saying that these pages are grouped together as a sequence making it acceptable for Google to crawl through those pages.

I hope that helps. Also, I'm not sure how SEOmoz handles the canonical in regards to duplicate content.

Thanks.

The "thin content" question can be tricky. Google's support article about this says that thin content is a page that doesn't provide users with "substantially unique or valuable content". Their support article about original content talks about the need for "authentic content".

Together, I take to mean you should err on the side of what is good for your users. Content is important, but what is really important is useful content. In you case, it sounds like you are giving visitors what they want - get in, get what you need, get out. That seems like there is value and authenticity there for your users. So long as you continue to see higher rankings, more/steady traffic from Google, then I wouldn't think you should worry.

As well, the other question to ask here if if you have received any manual actions about thin content in Search Console? I'm assuming not since you didn't mention that. But, just wanted to double to make sure you were checking for that.

Hey,

This is definitely a complicated issue, and there is some risk in making a move in the wrong direction.

Here are my thoughts which might help you out. Feel free to private message me or shoot me an email (see my profile) and I'd be happy to talk more.

On the hash solution, would that require JavaScript be enabled in order to access those pages or would you have a fallback solution for those without JavaScript?

If you don't have a fallback solution for those without JavaScript, you might negatively affect visitors with disabilities. For instance, some types of Ajax are challenging for people with disabilities to access (see here to start digging into that: http://webaim.org/techniques/javascript/).

Thing is, if you have a fallback solution, Google could still access those. However, Google may still be able to access those pages with JavaScript as Google can execute some forms of JavaScript. Given that, the more appropriate solution would be to use the robots.txt file. You mentioned, though, that the command you put in didn't seem to work since Google kept indexing those pages. Couple questions:

First, did Google index those pages after the change or had those pages been indexed prior to the robots.txt change? Things take time, so I'm wondering if you didn't give them enough time to adjust.

The other question would be whether or not you tested the robots.txt file in Google Webmaster Tools? That just gives you an extra verification that it should work.

Also, you mentioned something interesting about the Vehicle Detail pages: "these pages are not meant for visitors to navigate to directly!" Given that is the case, is it possible for your developers to add some sort of server-side check to see if people are accessing the detail pages from the listing pages?

For instance, on some sites I've worked a cookie is set when you've reached the listing page that says "this person is okay to reach the detail page" and then the visitor can only reach the detail page if that cookie is set. Without that cookie, the visitor is redirected back to a listing page. Not sure how exactly that would work on your site, but it might be a way to keep visitors who find those pages in a Google search result from seeing the incorrectly styled page.

I hope that helps. Like I said, feel free to email me or private message me if you'd like me to take a look at your site or chat with you about more particulars.

Thanks!

Hi, 1. Your redirect to www should work. If that isn't working, that might be a sign that mod_rewrite is disabled and in that case, I'd check with your hosting company to verify the server config.

2. As for the index.php, I wasn't able to get your code working. Here is a code snippet that should remove index.php from all your URLs. It is similar to what you are using, but matches in a different way.

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /.index.php\ HTTP/ RewriteRule ^(.)index.php$ /$1 [R=301,L]

Hope that helps. Thanks,
Matthew

Generally speaking, this isn't the worst problem you can have with your XML sitemap. In an ideal world, you'll be able to remove duplicate URLs from the sitemap and only submit a single URL for each page. In reality, most larger sites I've encountered have some amount of duplicate content in their XML sitemap with no real major problems.

Duplicate content is really only a major problem if it is "deceptive" in nature. So long as this is just a normal consequence of your CMS, or similar, vs. an attempt to game the rankings you are probably fine. For more about that check out this support article.

The other problem you may encounter is with your search results for those duplicate pages. That article makes mention that Google will pick the URL they think is best (more about that here as well) and the URL they deem the best will be the URL that surfaces in the search results. That may or may not be the same URL you or your visitors would deem best. So, what you might find is Google picked a not great URL (like one with extra parameters) and with the not great URL appearing in the SERPs, your search result isn't as compelling to click on as some other version of the URL may be.

Hey Kat. I'd tend to agree with Andy's response that moving this into one site makes sense. You could then redirect the local pages into the appropriate page on the main site, creating a single authoritative domain. You'd want to make sure as you do this that each local page is truly unique...if the Chicago and Detroit local sites both contain similar pages about a dog safety campaign, you'd want to consolidate those (probably) into a single dog safety campaign page that could work for both locations (or find a way to distinguish the content for each location).

Now, having gone through a few projects like these, I know full well that what is best for SEO or UX isn't always the most popular solution. Internal politics play a role, and I'm guessing you might be in a spot where some of the local chapters don't want to relinquish control over their site. So, as an alternative solution you could look for some other ways to link these sites together. For instance, you could have a dog safety page on the main site that all the local chapters can link to and possibly, let the local chapters adjust the content slightly via the link. As in, if the url includes a query sting referencing Chicago (maincompanysite.net/dog-safety.php?location=Chicago), the content on that dog safety page could be programmed to show Chicago's phone number and address. That way you have a definitive page that can rank, but also a way for local chapters to share that content through their domain.

A lot of that alternative comes down to content governance rules, communication about who creates what page, a clear understanding of how people link to sites, and probably some clear design/brand standards. It is a bit of a mess, but not an unrealistic reality if you can't convince all the stakeholders in the value of consolidating to a single domain.

Hope that helps!

Without looking at the site or this one page, but based on what you are describing, I would suspect the bounce rate is high because of an expectation gap. The people coming to this article sound like they are in the early stages of the buying cycle--they want information about the types of products available and how to use this product. Maybe many of these people aren't quite ready to look at category pages or product pages because it is simply too early in the buying cycle for that to happen. Your links expect one thing (products/shop/buy) but visitors expect another (more info).

In these cases to lower the bounce rate, you need some kind of in-between content. Something that moves people to the next step of the buying cycle. Basically, you need to solve for X in this equation: early pre-purchase research -> X -> product page. To start solving for X, I want to know what questions people have after reading this article. There are several ways to get that, but user testing with targeted customers can usually be a good place to start.

Another place to look is in regards to trust factors. Do the people coming to that informational article trust your brand? It seems like they are because of how long they spend on the page. However, it could be people trust the company enough for information and insight, but maybe not enough to purchase. Again, user testing this page to gauge trust factors could be helpful to clarify what more you can do here to get people to stick around.

Final thought - it may simply be that this page will always have a high bounce rate. This is where re-targeting ads can be helpful. You know people are interested in your proudct but aren't quite ready to look at products just yet. So, after they visit this page you should re-target an ad to them as they continue their research building up to purchasing the product.

Hey. I agree with what Martijn said that generally, you want to request links from more active sites. Those sites tend to have better overall quality, search performance, and a more active audience. The one thing I'll add is that sometimes you can find blogs that have great evergreen content (good rankings, good links, seem to have decent traffic, etc.) even though they don't have a lot of recent content. In these cases, a link to a relevant page on your site could enhance that evergreen content and sometimes site runners are willing to update old articles (even if they aren't adding anything new). For example, maybe an old blog post on a currently inactive site has a great recap of the best ways to do X (where X is a subject that hasn't changed much in years). You have a page that offers another way to do X or is somehow tightly connected, so including it in that older blog post could be of use to the people who find that old article.