Welcome to the Q&A Forum
Browse the forum for helpful insights and fresh discussions about all things SEO.
Google recommends blocking all Internal Search Results in the Robots.txt file. I suggest creating a product collection or category for Edward Scissorhands Themed Costumes and linking to that instead. This way you can customize the content on the page just as if it was any other category page.
Becky,
"Thin" is a relative term when it comes to content. There is no hard-fast rule about how many words to have on a page, and let's not forget that words are not the only form of content. Multiple product images, product demonstration videos, user-generated reviews (as you mentioned) are all great types of content to have on a product page.
Seek to answer the obvious questions for the visitor, and do not use manufacturer-supplied content.
Some examples of "obvious questions" for the user:
If it only takes 100 words to answer all of the obvious questions then that's probably OK for most products. If it takes 300 words then that's what you'll need for a good user experience.
Think about your shoppers, not search engines, and you'll probably do fine. Your shoppers don't want to read the same product description that's on all of the other sites. They may want to read lots of feature / stats data if it's an expensive or complicated product, but probably not if it's a plain white T-shirt.
Good luck!
Thank you Donna. We have seen a lot of success with the pruning method for outdated content. I'm glad the article has helped you. 
I haven't had any trouble using JSON-LD for organizations and people. I have only used in-line product schema so far for products. You could try adding the in-line markup if you haven't already, and leaving the JSON-LD script up.
Hello Adrienne,
SLI is going to have some features that BigCommerce isn't going to have in their default site search. However, as you said, BigCommerce has come a long way in this area. It really comes down to features, and what is important for you.
For me, I look at three main areas:
In all three of those areas, BigCommerce has it covered. It's easy to use, provides relevant results (and search suggestions), and you get reports like Keywords Without Results and Worst Performing Keywords (among others) which help answer all kinds of questions, from which pages to optimized to which products to source. I used to send the buyers at one store these reports quarterly, and they sourced many new, top-selling products because of it.
If you're missing any of the SLI "learning" features in BigCommerce's standard search, you may be able to get them with an add-on like this: https://www.bigcommerce.com/apps/searchspring-advanced-site-search/ (Note: I haven't used SearchSpring).
Hello Nick,
I'm assuming this is the tool you're talking about. If not, please point me to it:
https://www.thinkwithgoogle.com/tools/customer-journey-to-online-purchase.html
I don't see a "Design" industry option at all. I do see "Finance" and that would be the one to use if that is the target audience.
"So if they were going to put out some custom content targeting large UK businesses in the finance sector..." I would input this:
Industry - Finance
Business Size - Large
Country - UK
Channel - Organic Search (or whatever channels you're exploring)
Technically, I think the tool was meant to be used for you to put in the size and industry of your (or your client's) business. However, since the content you're producing is specific to another industry, you'll get more actionable information from the tool if you use the size and industry you're targeting.
iCourse,
That's unfortunate. I tested the humidor product page in Google's Structured Data Testing Tool and the product schema does include the aggregate rating markup.
Google doesn't always show rich snippets just because you have the right code. Other factors come into play, including the relative trust they have in the website as a whole, and the page specifically. However, you had them for the review markup before so I would advise adding the review markup to the page, and putting the aggregate rating Schema markup in the HTML header area using JSON-LD, as described here:
https://builtvisible.com/micro-data-schema-org-guide-generating-rich-snippets/
It would look something like this:
There appears to be two errors in your video markup related to a missing video thumbnail and upload date, but that's a separate issue.
Dmitrli,
Regarding the blocking of affiliate URLs in the robots.txt file, you can and probably should do this, by first running those through an internal link redirect. For example:
If the Merchant gives you the following URL:
http://www.merchant.com/affiliate-id=123&landing-page=abc
You wouldn't show that URL to Google or users. Instead, you would show them:
http://www.youraffiliatesite/affiliate-link?id=123
And then in your robots.txt would be:
Disallow: /affiliate-link?id=*
Hello Kevin,
Which meta tags are you trying to update?
Have you had any developers work on the site who may have hard-coded something else into the template instead of the Magento default? For example, maybe your product page Title Tags are based on the product name and the Meta Descriptions use the product description?
And don't be surprised if the rankings for those products fluctuate wildly, as you are essentially giving and taking away good pagerank from your home page on a daily basis.
Maybe you could have a drop-down div to "see more top products" or something?
Bryan isn't wrong, but I had a quick look and I don't think Trip Adviser is using rel next/prev on those pages. They don't seem to be using rel canonical or any robots meta tag, and I didn't find the pages in the robots.txt file.
I think this is a case of a big brand getting away with things a smaller brand probably couldn't do. Happens all the time.
Are you using your own subdomain or one somewhere else (e.g. akamai.com)? You should use your own subdomain, if possible.
Was this a change from a previous version that didn't use a CDN? If those images were/are hosted on your primary domain be sure to match the filenames and paths as closely as possible to what they were before.
If you're doing that you shouldn't have a problem once the sitemap is submitted.
For more information please check out this post:
http://www.goinflow.com/four-seo-best-practices-for-using-a-content-delivery-network-cdn/
How do you know that Google only attempts to crawl the primary domain URL (i.e. the .html page)? Are you checking log files?
Is the crawler you're using set to crawl external URLs? If not, that could be the issue. Technically a subdomain is a totally separate website so most tools don't crawl them by default.
David,
I can see the frustration. It would appear to a searcher on Google that the page for this class hasn't been updated since 2013 because Google is using the Schema markup you have around the review, which is:
A quick fix that could help until you get this figured out would be to change the published date on the review to a more recent date in 2015.
I do see that you have placed the "datePublished" markup within the Schema.org/review container, but Google seems to be interpreting it not just that way, but also as if it was on it's own to describe the entire page. In other words, it seems to be treated like this: https://schema.org/datePublished .
I see that you have itemtypes for an offer, dates, reviews... but not one for the page itself. Perhaps just below the HTML header of that page you could define the web page's publish date using this itemtype: https://schema.org/WebPage.
It would would begin with:
itemscopeitemtype="http://schema.org/WebPage">
And would contain:
<meta< span="">itemprop="datePublished"content="2015-01-01"> (or whatever the real publish date is)</meta<>
And would cover the entire page down to:
Another option could be to go with JSON-LD instead.
Hello Steve,
It is difficult to say how long it will take because Google handles different sites at different speeds depending on things like domain-level trust metrics, how often the pages get updated, how easy the site is to crawl, etc...
Generally speaking, bouncing back after a complete site migration takes a couple of months, which can be shortened by following best practices, most of which it sounds like you've already done.
I would submit a new XML sitemap (replace the old one) and then fetch these new pages as Googlebot. Then if you want to write a useful blog post that links to those pages it would help get them crawled and indexed, while also building some internal pagerank for them.
Good luck.
Have you considered using the Campaign parameters in Google Analytics instead?
Campaign Source: 3876_537
Campaign medium: affiliate_link
Campaign name: prequalify-2
Something like that?
I typically advise making promotion URLs "evergreen" so you can re-use them. For example, if you know you're going to have a Christmas sale every year don't make the URL /christmas-sale-2015/. Just /christmas-sale/ will do. Then when the promotion is over you can put up messaging saying when they should check back (if it's a regular promotion) and provide a link to your main promotions page. You can just re-use this same page every year and it will gain more and more links over time and become increasingly powerful.
If the promotion is a one-time deal and not something that you do each month, quarter, year... then I would 301 redirect the out-of-date promotions pages to the main promotions landing page. You can update the content on that page regularly and optimize it for things like "sales, discounts, deals, promotions, promos...".
Assuming the links you add to the top navigation are followable href links I think this sounds like a good idea for the reasons you state, as well as sounding more mobile and tablet friendly. It would be good to see the site though.
Hello SEO32,
I apologize for the delayed response. There are several good questions here. They're also complicated questions, which don't really always have a single "correct" answer. So much revolves around the specific situation, and without seeing your website it is difficult to say what is best for you. Also, much of what we think we know about this kind of stuff is either based on what Google tells us (which isn't always the truth) and what we've observed and deduced from our own experiences (which aren't always the same). True "testing" of this stuff one variable at a time isn't always possible so we rely on best practices and our own experience.
That said, I will attempt to answer your questions with what I would probably do in most situations, including links to more information when possible.
Do we implement self referencing canonical URL on the main page and each paginated page?
Here's what Rand says, and he's probably seen way more data than I have:
"Whatever you do, DO NOT:
Keep in mind that post is from 2010, and I think before Google said a "View All" canonical <a>was their preference</a>.
I have seen plenty of sites do well ranking the canonical category page, and with indexing most of the product pages, while all paginated pages had a rel canonical that referenced the first page in the series (i.e. .com/category/ or .com/categry1/category2/). It probably helps that they had good XML sitemaps for product pages, and plenty of internal linking, unique content on category pages, etc.
I have also seen sites do well using rel next/prev without rel canonical, or rel next/prev with self-referencing canonicals on paginated category pages.
I think where you run into problems is when you also allow the facet/filter/sort versions to have self-referencing rel canonical tags.
Here is what I advise in most cases:
Use rel next/prev (not because I think it works, but because Google says to and I don't think it hurts) along with self-referencing rel canonical tags, and "follow,noindex" robots meta tags on paginated pages.
Always include a followable link to the first page in the series from every subsequent page. For example:
<previous>first...1...25...26...27...last...</previous>
I recommend always having a first and last page link. The first is obvious because it means pagerank is going to flow into it from every other page in the set, giving it the most internal links of all. The last is more of a crawlability and usability thing. For users it helps us figure out how much further we have to go. It does the same thing for search engines. Instead of blindly following a path that may or may not have an end, a message is sent that tells a spider how much further it has to go. I don't know if Google takes advantage of that signal or not, but it just makes sense to include it. If you want to get fancy you can try making the 'last' link flash or javascript or something so it doesn't pass (as much?) page rank.
The category root pages usually have links from site-wide navigation, unlike the paginated versions, which further establishes it as the page that should be ranked highest.
Make sure the first page in each series is indexable, and has content that does not appear on the paginated versions. Also, make sure that ?p=1 doesn't have a self-referencing canonical tag, but references the root page for that series (e.g. /category1/category2/).
All subsequent variations (e.g. color, size) should rel canonical back to their root page. For example:
/category1/category2/?page=2&size=s&color=blue would have the following URL in the rel canonical tag:
/category1/category2/?page=2
Which happens to be followable, but not-indexable, and has a self-referencing rel canonical tag.
In this way you give search engines a strong signal about which URL in the whole set is the strongest (i.e. /category1/category2/) because it is indexable, has its own content, has the most internal and external links, is the simplest version of this URL pattern, and is at the root of the directory. You're telling search engines which page is next in the series, and that this page is first in the series. You're telling search engines which page is last in the series, as well. Google usually does an awesome job figuring it out from there. There are always exceptions.
Do we implement noindex/follow meta robots tag on each paginated page?
I would. Consider this from Google's perspective, or from that of a searcher. Someone types "Blue Flower Dress" into Google. Is the best page to return a deep category page full of blue dresses, one of which happens to have flowers? Or would it be the Blue Flower Dress product page? I can't think of any reason why I would want to land on page 3, where what I'm looking for is listed among dozens of other things, when I could just go straight to the thing I'm looking for.
Likewise, if someone searches for "Blue Dresses" is the best page /dresses/blue/?page=3 (paginated page in the Blue Dresses category), OR /dresses/blue/ (the very first page of the Blue Dresses category), which also has useful content about blue dresses?
Long story short, when it comes to transactional eCommerce queries, they're usually either looking for a product page or the first page of a specific category or sub-category. Or sometimes the home page. Therefore, I don't see any reason for allowing paginated URLs to be indexable in most cases. Non-transactional eCommerce content is different (e.g. buying guides, comparison charts, reviews...) but I still wouldn't allow paginated pages to be indexed in most cases.
Slightly Off Topic - Filters/Facets/Sorts
Or perhaps the category is "casual dresses" and "blue" is specified in the "color" attribute. In this case, would the best page be /dresses/casual/?color=blue , /dresses/casual/ or /dresses/casual/?color=blue&page=4 for someone who Googled "blue dresses"? I've bolded the one I'd prefer as a searcher.
Here again, as with the internal search results, there is an opportunity to use real data to inform your decision. Pay attention to the facet/filter/sort URLs most accessed by shoppers and consider turning those into category or collections pages with their own URL pattern (e.g. /dresses/casual/blue/). One example I come across all the time is when "Brand" is a filter instead of its own limb in the category structure. If people are shopping by brand, as they do with most consumer products, then you should have a brand subcategory under each major top-level category. If I search for Levi Jeans Google doesn't want to send me to a "pants" page where I have to set a filter to see only Levis. I should go to pants/brand/levi/ . If I Google Chefmate Pots I want to see cookware/pots/brands/chefmate so I don't have to set a filter after I get there.
This doesn't mean all filter pages should be turned into category pages either. Use your best judgement based on the pages most of your users are accessing from the navigation and filters.
Do we include the canonical URL for each paginated page in the sitemap if we do not add the meta robots tag?
I would add the robots meta tag. Please let me know if I've misunderstood the question.
We have a view all but will not be using it due to page load capabilities...what do we do with the view-all URL? Do we add meta robots to it?
I would add a meta robots "index,nofollow" tag, and would also use the canonical page's URL (e.g. /category1/category2) in the rel canonical tag.
For website search results pages containing pagination should we just put a noindex/follow meta robots tag on them?
This is one of those situations involving crawl budget potentially being eaten up by an infinite amount of pages. I would consider blocking the internal search result URLs in the robots.txt file. They are of no use to Google, as they consider a search engine returning search results with links to more search results somewhere else a bad user experience. This is also what Google recommends in their Webmaster Guidelines:
"Use robots.txt to prevent crawling of search results pages or other auto-generated pages that don't add much value for users coming from search engines."
However, I would also make use of those pages internally. Rather than relying on a search result page for things people often look for, track what is being searched for and create static, indexable pages. For example, try "Collections" pages on eCommerce sites, as well as FAQ pages, or "Industries" or "Use Case"-type pages on lead generation sites. This is a much better user experience for someone arriving on that page from a search engine.
We have separate mobile URL's that also contain pagination. Do we need to consider these pages as a separate pagination project? We already canonical all the mobile URL's to the main page of the desktop URL.
I think you should if that's the way you're handling it. Here is a post I did on mobile best practices. It covers some other options. I would also add a rel=”alternate” tag in the HTML header of the desktop page, which alerts search engines to the corresponding mobile URL and helps define the relationship between the two pages.
The bottom line for me is to always think about what would be the best experience for someone searching from Google for something, and to try and use all of the various technical options to ensure that is the page I'm telling Google they should rank for that query, or those types of queries. The 'best practice' changes, depending on the situation.
I hope others will join the discussion with their own experiences and findings.
It looks like your last line is just redirecting one page? This has worked for me to redirect them all to their corresponding pages on the new domain (*You'll want to test this first):
<code>RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !newdomain.com$ [NC]
RewriteRule ^(.*)$ http://newdomain.com/$1 [L,R=301]</code>
Hey Tony,
Thanks for following up like this. I think Asian Travel Tips is a much better, more brandable, domain than the other ones you have listed.
Google may tell you that you don't have a "manual action" while you may have an algorithmic one. The people on the team you contacted (at the time it was called Google Webmaster Tools, but whatever they're calling it this week) probably have no way of knowing whether your site has an algorithmic penalty, or is being given lower rankings algorithmically.
Generally speaking, fewer domains is better than lots of more niche microsites if they're all part of the same theme - in this case travel to Asia. Here is a post about this concept:
https://moz.com/blog/2-become-1-merging-two-domains-made-us-an-seo-killing
Here's what Rand has to say about it:
https://moz.com/blog/rebrand-or-redirect-my-site-consolidate-multiple-sites-whiteboard-friday
I had a look at the screenshot you sent and the site looks good. Keep posting unique, useful content about traveling throughout Asia and you should be fine. I like that you're leveraging the Trip Adviser connection, as it adds trust for the user.
Good luck!