Hi Ken,

It depends a little on how the complaints are organised within the site structure, what links they have, and what traffic these pages bring in. Unless you think domain authority is a particularly big factor in the competitive space the site operates in, I wouldn't fixate on DA. Questions you do want to answer:

• Crawl the whole site, preferably using the Google Search Console and/or Google Analytics API with Screaming Frog. Do these complaints bring in (useful) traffic? Surely part of what makes the 311 service useful for community managers is that people in their community can easily comment and see the comments of others? Thinking further down the line, if the site is difficult for people in the community to find, will they use it less, and thus will community managers see less value in the service over time? Indirectly, people leaving complaints is probably a good thing for the service; do they usually do this after searching for "potholes on main street"? This is all guesswork on my part, as I haven't seen the site.
• If you do have a lot of traffic to the complaint pages, is it useful traffic? Could you afford to lose it (because that may happen if you noindex)? Remember to bear in mind the second-order effects: if nobody complains any more, the manager doesn't need a 311 service!
• Do you actually have valuable (external) links to the complaints? We can't guess at that—the only solution is to use Open Site Explorer, ahrefs, Majestic, etc...

Without knowing more, I'll just say: there probably isn't value in having an indexed page for each complaint, but there might be value in having indexed collections of complaints, optimised for neighbourhood or street. So if there are 6 complaints about potholes on main street, a first step might be for each individual complaint-page to canonical back to the page detailing all complaints about main street. And if complaints are really that brief (1 or 2 sentences), eventually I'd prefer to change the site structure altogether, so that each complaint didn't get its own page at all, but that I had one page for each neighbourhood/street/etc, with the complaints listed there and preferably summarised in some way (i.e. "8 pothole complaints", "9 traffic light complaints, etc.) That kind of view might be useful if I was a resident of the place. You would still have to deal with pagination, especially if the number of complaints is large, but that's still going to be far fewer pages than if you have one for every complaint individually.

Hi Mike,

I wouldn't worry about it—it won't have a major impact. Google will see all those H1 tags, but unless they get the sense, from the rest of your content, that you're relentlessly stuffing the keyword into the article text (and it doesn't sound like you are), it'll be fine.

What I would want to make sure of, though, is that Googlebot is definitely rendering the page in the way you expect. Sounds as if, rendered properly, only one H1 and header image should be visible on each device type? You should take a look at the page using the Fetch and Render tool in Google Search Console to make sure that, whether as desktop or smartphone, everything looks as it should. If you're carrying out this exercise across many pages on your site, you will find it faster to use Screaming Frog's "render screenshot" option.

Did the "pending" message go away in the end? Unfortunately you're fairly limited in what you can do with this. The message likely indicates/indicated that one of the following was true:

1. Google had difficulty accessing the sitemap (though you did say no errors)
2. It was taking a long time to do it because of the large number of links

You could try splitting your sitemap up into several smaller ones, and using a sitemap index. Or have you done this already? By splitting it into several sitemaps, you can at least see whether some index and some don't, whether there do turn out to be issues with some of the URLs listed there, etc.

You can also prioritise the most important pages by putting them into their own sitemap (linked to from the sitemap index, of course), and submitting that one first. So at least if everything else takes longer you'll get your most important landing pages indexed.

Hi Zack,

Unfortunately, this is just down to sampling. Results in the interface, in particular, are very heavily sampled. There's a limit of 1000 rows per response when using the interface, but this goes up to 5000 when using the API. So the best you can do, really, is to use the API and pull out as many combinations of filters as you can.

I wrote this script for that purpose, and my colleague Dom also wrote about it in this Moz post.

It's an interesting question. I'll extend your example slightly, so that we have:

• Page A, with a canonical pointing to Page B
• Page A also has a regular link to Page C
• Page B does not link to Page C at all

At the crawling stage, Googlebot will parse all of the links on Page A. So in this case it discovers both B and C (if it doesn't know of their existence already). This is uncontroversial stuff—the use of the canonical tag doesn't affect crawling/discovery.

You might then assume that Google—if it decides to obey the canonical instruction, which of course it doesn't always do—will pass all of Page A's link equity to Page B (minus the small fraction), and then no longer count that link from A to C in the link graph. Almost like a redirect, but for bots only.

However, that doesn't seem to happen. The link from A to C is still included in the link graph. PageRank (or whatever's replaced it) may still flow through that link, even though Page A is not to be indexed.

So to answer your original question, the content of Page A will not be ignored, and neither will its links. The unclear bit is how much Google will value that link from A to C.

What exactly are you planning to render server-side? In principle, you shouldn't have anything to worry about if you render everything server-side, provided the rendering isn't so slow that it affects Google's measures of page speed.

What do you see when you use the 'Fetch and Render' feature in Search Console at present?

Hi Jon,

The information showing up in the rich snippet has been taken from the very well-structured table that appears on the right-hand side of many Wikipedia pages. This data is very easy for Googlebot to read (because it's in a table), and regarded as trustworthy (because it's on Wikipedia). Depending on how Google interprets your intent, it may or may not borrow from this well-structured data in the rich snippet.

For example, on the Wikipedia page for Optical Express, there is again a table that lists key data about the company: the year it was founded, who the founder was, and which products it sells, among other things. When I search for "optical express contact lenses", the Wikipedia entry doesn't have a rich snippet, even though contact lenses are listed in the product field in the table. If I search for a less commercially-minded term, like "optical express founder", I do get a rich snippet with information about the company and founder (see the two images I've attached here).

So the point really is that there are no guarantees, and no direct control over the rich snippet, but you and your clients should definitely expect to see a lot more of this kind of thing in future, whenever Google is confident that a rich snippet provides a good answer.

As for what you can do: your client won't have Wikipedia's authority, but you can use structured data, such as JSON-LD or Microformats, to make the meaning of your words more transparent to Google. This will increase the chance, at least, of meaningful rich snippets with information about your client's company or products. Tymen has linked to a couple of useful resources, which you should use to ensure that you're implementing the structured data correctly.

46K6eW5 FcNv710

Hi Justin,

Sorry for the late reply here. Yes, I likely would do that. As long as the site categories are set up properly, you shouldn't require any product attribute pages to make a product discoverable for Googlebot. And the pa_ attribute pages tend to make for a poor landing page experience. If a product/attribute combination is especially important or profitable, I'd usually set up a custom landing page for that, rather than rely on the product attribute archive pages.

Hi Neil,

Don't host the video in two separate locations. You don't want to publish it to Youtube and also store it on your own server, for example. In light of your latest comment, I'd suggest you publish the videos to Youtube, embed those videos on your site, and encourage the hotels to do the same. You should associate the Youtube channel with your own site, and provide links back to your site from the videos (as Andy suggested). Follow the steps outlined in Youtube's guide.

In an ideal world -- a world where all 90 hotels were happy to link to your website -- this advice might be different. Ideally, you'd have links to your site. But if you self-host, it seems likely that you'll have hardly any views: your hotel partners won't link to the videos, and the videos won't be easily discoverable. By hosting on Youtube and encouraging video embeds among your hotel partners, you can at least, as you said, generate a lot of interest around the content. Google does favour Youtube videos in SERPs, so this strategy should help your Youtube channel perform well for queries related to your partner hotels. You can use cards or annotations in the Youtube videos to direct visitors to your site, as well as providing a link in the description.

Hi Justin,

Yes, you're correct in your response on Nov 26: XML sitemap exclusion won't guarantee that the pages aren't indexed, as they can still be discovered by Googlebot. Instead, you'll need to edit your Wordpress theme. I'll give some instructions for the 'Storefront' theme here, which should work in the majority of cases, but you may need to amend them if your theme is heavily customized.

When the page loads, it'll call the get_header(); Wordpress function, and pass the argument 'shop' to it, like so: get_header('shop');

That will prompt Wordpress to go looking for a file in the theme root called 'header-shop.php'. If that file doesn't exist, it'll load the default header.php file instead. If you do have a header-shop.php file, edit it to add the meta noindex tag on category pages. If you don't have a header-shop.php file, make a copy of header.php and rename the copy header-shop.php, saving it to the root folder of the theme.

Now in the header-shop.php file that you're amending or have just created, add something like the following before the closing tag:

if ( is_product_category() or is_product_tag() ) {

echo "";

}

You should take care to ensure that the conditional statement there is working: you don't want to inadvertently noindex all of your shop pages! So test carefully on a local version of the site, and make sure that you aren't seeing noindex tags in the source code of the non-taxonomy pages.

I'm afraid I don't know the answer to your second question. If I had to hazard a guess, I'd say it's because the developers would receive more criticism for enforcing noindex tags on certain categories of page than for not providing a noindex feature. If they put noindex on taxonomy pages by default, for example, and didn't provide an easy plugin for removing it, they'd probably get complaints about that. Or it just isn't an important enough issue in terms of the overall WooCommerce development roadmap.

Hi Chad,

First off, you're right to be thinking about adding product attributes for the size, colour, etc. You should definitely do this.

I wouldn't recommend tags unless there's a strong reason to use them. Tags can be of genuine use on a blog, by providing users a way to navigate a group of related posts, without the blog author having to devote a whole category to it. But eCommerce sites, depending on their size, can already have a pretty difficult time with duplicate content, and it's hard to see how tags would improve the user experience more than tightly-focused subcategories.

If you have a category called "beds", for example, it makes more sense for "double beds" to be a subcategory within that, than to be its own tag. WooCommerce does support nested subcategories, which should allow you to get pretty granular if needs be. You can make use of breadcrumb navigation this way as well.

Finally, on the subject of product attributes again, note that WooCommerce adds attribute filters to the URL as a parameter. So if searched for double beds on your site, the URL would resemble the following:

yoursite.com/beds/double-beds/?min_price=250&max_price=600

You should make sure you've got rel=canonical in place. Also, given that your client is a search engine, I imagine they'll have quite a lot of product pages. To help Google use their crawl budget efficiently, you might add some lines like the following to the robots.txt file, so Googlebot doesn't try to crawl any commonly-used parameters:

Disallow: ?min_price=

Disallow: ?max_price=