Welcome to the Q&A Forum

Google talks about this as part of Dynamic Serving of content. Here is their article, which also includes tips on how to distinguish user agents (including how to signal this to Google):
https://developers.google.com/webmasters/mobile-sites/mobile-seo/configurations/dynamic-serving

This is an okay practice and I'd not had any Google penalties when I've utilized it. The big concern with doing this type of dynamic content shift for different devices is to avoid cloaking, which Google mentions in that article as well (be sure to click on the link in that Dynamic Serving article for more about cloaking). So long as you avoid cloaking, you should be in okay territory.

My advice is to test out your user agent matches thoroughly - I'd even go so far as to try this on one or two pages with some simple changes for each user agent and then make sure Google indexes those pages correctly before rolling this out to your entire site.

Hope that helps.

Hey Lewis,

I would imagine it is possible to merge the two sites with limited implications. From a pure SEO standpoint the biggest consideration factor is if there is any negative "baggage" associated with the B2B site--especially spammy backlinks or any wonky technology that would impact the B2C site (speed, redirect issues, etc.). Given that, I'd do a careful review of the B2B site first to evaluate backlinks to that site and any errors reported about that site (using something like Moz's crawl tool and/or in Google Search Console).

The other potential risk is if there is any duplicate content that would be created as a result of the merger of the two sites. For instance, if you have a page on the B2B and B2C sites about Product X, after the merger you'd potentially end up with two pages about Product X. From what you said, it seems like the B2B's site content would be hidden behind a login and wouldn't be accessibile to bots. If that is the case, then maybe this isn't much of an issue. But where this is an issue, I'd also work to figure out the sitemap of the merged site and map out any link changes or redirects that are required to implement that new sitemap.

Along with SEO considerations, there are of course non-SEO factors to consider that could have indirect implications on SEO. Would there be any harm in the customers of the B2C side knowing the B2B trade side exists? If so, that could potentially harm the visitor experience and the brand which could negatively impact clicks, social shares, link building, etc. in the future. Likely not a risk, but I've seen a handful of companies who've merged their two sites only to find that they should have kept their audiences more segmented.

Hope that helps!

any duplicate content that would be created as a result of the merger

Yeah, that would probably make the most sense. For sites where I've done something like this before, it is usually a single page (or maybe a few pages, depending) that talks about the trade program, answered common questions, allowed login, and encouraged signup. You could then promote that page(s), optimize it for appropriate terms, get links going to it, etc.

The best way to do this is by adjusting the .htaccess file. The htaccess file directs traffic to the correct page very quickly and efficiently. (An alternative would be to go through WordPress but typically this isn't an efficient alternative.)

The htaccess file is located in the root directory - /httpdocs, /public_html, etc.

At the very end of the htaccess file, add a new line and on that line, you will want to use a line like this. Update the URLs to match whatever you want to redirect from and to.

redirect 301 /servicos-de-marketing-digital/publicidade-online/ http://digitaldiscovery.com.pt/new-page-url-here

The first URL (after redirect 301) is the old URL you are redirecting from. This needs to be a relative URL back to the root directory of the website. The second URL (after the space) is the URL to the new page you are redirecting to. This needs to be an absolute URL (even if it is on the same site).

A couple words of warning on the htaccess file:

First, make sure your URLs do not have any special characters and if they do, make sure you escape them. (Space becomes %20, for example.)

Second, before making any changes to your htaccess file definitely create a backup of what the current htaccess file is. If you make a mistake in the htaccess file it can return an internal server error for your entire site. So, be prepared to roll back if something doesn't go quite right!

There is a good resource on htaccess 301 redirects here. It also talks about a meta refresh option but I'd avoid that as it isn't as good for search engine purposes.

http://www.tamingthebeast.net/articles3/spiders-301-redirect.htm

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,

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.

I'd agree that the main domain would be ideal but if there are too many business reasons (or financial burdens), you would probably be okay with a subdomain. A subdomain does get some benefit from the root domain.

Certainly, if you do go with a subdomain route you'll want to make sure that you do all the right things around that subdomain (links, optimization, social, etc.) so that Google/Bing see indicators not just to the root domain but the subdomain as well. Along with that, you'll want to have plenty of internal linking between the main site and the subdomain site.

One other thought is, is it possible to do this as a sub-directory (suretybond.com/storefront)? A sub-directory would be considerably more beneficial from an SEO standpoint since you don't have to worry about how much link juice/trust/authority is passed from the root domain to the subdomain. I realize technically that isn't always possible given the way things are configured.

Also, there was a good blog post about this on SEOmoz from 2009 that you might want to check out. http://www.seomoz.org/blog/understanding-root-domains-subdomains-vs-subfolders-microsites

Hi,

I have a client's site that posts job openings. There is a main list of available jobs and each job has an individual page linked to from that main list. However, at some point the job is no longer available. Currently, the job page goes away and returns a status 404 after the job is no longer available.

The good thing is that the job pages get links coming into the site. The bad thing is that as soon as the job is no longer available, those links point to a 404 page. Ouch. Currently Google Webmaster Tools shows 100+ 404 job URLs that have links (maybe 1-3 external links per).

The question is what to do with the job page instead of returning a 404. For business purposes, the client cannot display the content after the job is no longer available. To avoid duplicate content issues, the old job page should have some kind of unique content saying the job is longer available.

Any thoughts on what to do with those old job pages? Or would you argue that it is appropriate to return 404 header plus error page since this job is truly no longer a valid page on the site?

Thanks for any insights you can offer.
Matthew

This URL contains some advanced tricks to specifically prevent prefetching by Firefox. I've only tried to the htaccess mod_rewrite technique. However, I modified that technique to send prefetch attempts to an empty file instead of the normal 404 page (saving resources): http://www.petefreitag.com/item/312.cfm

I would avoid only showing tags to Googlebot. It does look a little spammy and like cloaking but more than that, adjusting content for Google can be an involved coding process that comes with risks (accidentally showing something else to Google, etc.).

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).

Hi,

Are your pages manually driven or created out a database system? If they are in a database of some kind, you should be able to query for the URLs and generate the XML sitemap. If they aren't able to generate the sitemap to /sitemap.xml file, make sure you put the URL of the sitemap on your robots.txt file. (For example, if the sitemap ends up being sitemap.php instead.)

If they aren't database driven pages or if you developers aren't able to create an XML sitemap for you, I'd recommend this service:

http://www.xml-sitemaps.com/standalone-google-sitemap-generator.html

You can setup a scheduled job on your server to run this on whatever schedule you want. I've used it on a number of client sites where the data drive XML sitemap isn't an option.

Hope that helps.

I am pretty picky about linking out to other websites and rarely have an external link more than once per page unless it makes complete sense to have the multiple external links on that one page. That said, it does depend on the site and the page. If it is a blog, I'm more generous with external links. Still though, with any external links I make sure it is a site I'm willing to link to (good authority, good fit for users, etc.).

Given that I'm only linking out to trustworthy sites, I usually don't add in a rel nofollow. On the few occasions I've had to link to a site that is questionable, I'll always nofollow that link.

On your question of the <a>tag...when I do link out, I do always put it in a regular link just so that I don't make the website harder to use. I've tried the plain text route before and didn't see any huge SEO impacts but did see a huge negative usability impact.</a>

<a></a>

Not sure what your problems are with PHPLD and why you want to change, but for an alternative to PHPLD (but staying within PHP), you may want to check out phpmydirectory.com. I've only worked a little with both, but from what I've read and heard from other developers, phpMyDirectory has better options when it comes to plugins. Hope that helps. 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.

Hi,

Let me back up a step. When you say remove duplicate content, do you mean delete the page? For example, pageA.html and pageB.html have the same content. In your example, are you asking do you delete pageA.html or delete pageB.html? I wouldn't delete either page as both pages likely have traffic, links, etc.

Instead of deleting, you want to pick which page is the canonical version of that page. More simply, when somebody Googles the terms that page is targeting, do you want pageA.html to show up or do you pageB.html to show up? If you decide you want pageA.html to show up, then you need to redirect pageB.html to pageA.html. That way, if somebody goes to pageB.html they end up on pageA.html. If you delete pageB.html and somebody goes there, they'll end up on an error page.

Now, on where question...in terms of deciding what version is canonical, I would suggest you look at authority first and foremost. If the domain authority in OSE is higher for pageA.html than it is for pageB.html, keeping pageA.html makes sense. Things like URL structure are only mildly important, especially when making decisions like this.

Hope that helps. Thanks,
Matthew

You are correct that the Search Analytics queries report does limit down to 999 queries. However, when you load the Acquisition -> Search Engine Optimization -> Queries report in Google Analytics, you may be able to see more than 999 terms. I just double checked in a dozen or so accounts and all reports in Google Analytics were plus 999, though that may or may not be changing based on Google's new updated to the Analytics report. Also, keep in mind though that there is a limit to how long the data would stick around - for clients I work with ongoing, I export the reports monthly just so I don't lose the limited data you do have.

As Charles said, though, this data about queries isn't always reliable and it is limited in what you can get out of this data. That said, if you are using it for a general idea of what terms people found you for and what pages were related to which term, it can be helpful. Certainly not as good as the pre-"not provided" days and you obviously can't rely on it to calculate ROI, but it at least gives you an idea of terms and a relative idea of performance.

As for other ways to get around not provided and find those queries, here are some articles with some good tips and tricks:
https://moz.com/blog/landing-pages-report-in-moz-analytics
https://blog.kissmetrics.com/unlock-keyword-not-provided/
http://searchenginewatch.com/sew/how-to/2297674/google-not-provided-keywords-10-ways-to-get-organic-search-data

From the sounds of it, you need to set canonical URLs as there probably is no easy way to block the review or navigation URLs (since those are on a product-by-product basis). For example, on the review URL (blah-blahtext/reviews/category/categoryname) you would have a canonical tag to blah-blahtext.html. On the category URL, you could set the canonical to product-name.html. That way if Google/Bing see the URLs and the duplicated content, the canonical indicates that those URLs should be treated as an alternative version of the canonical URL.

Hey John,

Even if Authority Labs can do that (and I agree, it seems unlikely), my question becomes: who really cares? Seriously, what makes knowing that information useful? Does it actually tell you something new to know you don't show up in 59 million results (beyond the top 50, who cares)? I don't see the point and I think it is silly the other guy keeps bringing it up.

You already know you aren't ranking high enough for that term to matter but you know you need to. That means the real question is, "okay, what do we do about it?" If you can answer that question, you add something new to the conversation.

As others have mentioned, earning those rankings requires link building, authority building, social connections, and writing content that differentiates you from your competition (and you have big competitors).

Hope that perspective helps.

Matthew

For what it is worth, I'm in the US and seeing the 999 limit on all my accounts and domains. So, I guess that means the clock is ticking and if you don't have that limit yet, then you better get downloading fast!

One other advantage to no extension on the URL is that those URLs are easier to read and look friendlier in the search results. Obviously, a part of SEO is making those results look as good as possible. Though I've not tested it, my own experience has been that I get more visits to landing pages without extensions from similar keywords.