The community and content working groups would like to be able to lower the search engine ranking for some of our content by inserting no-index, no-follow, or equivalent tags into some posts and threads.

Deployment instructions

  1. Download the 7.x-1.x-dev version of the Metatag module
  2. Enable metatag and metatag_ui.
  3. Go to admin/people/permissions#module-metatag and assign permissions.
  4. For more fine-grained permissions, run "drush vset -y metatag_extended_permissions true" to enable the hidden variable. This adds additional permissions for each available metatag.

Usage instructions

To override meta tags for a specific node:

  1. Edit a node.
  2. Scroll down to the "Meta tags" vertical tab.
  3. Override any of the default values. The noindex and nofollow options are within the Advanced fieldset.
  4. Save the node.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drumm’s picture

How much is "some" and how often are updates expected? We can hard-code a handful of node IDs, or we can add a permissioned field for a UI.

greggles’s picture

Can you provide some examples of how you'd use this? I read the most recent content WG minutes and didn't see mention of it (thanks content WG for posting those!).

kattekrab’s picture

@greggles - there's a particular example that lead to this request that I don't want to link to because that would further add to its google juice. Other ideas have been thrown around for how else we might use this for moderating user content.

The main example involved semi-libellous user comments. We don't want to censor users, but we also don't want to broadcast comments that border on libellous, defamatory or discriminatory speech. We have an example where our search engine ranking is doing harm to a business in our community, and rather than delete the post in question, we'd rather work to lower its ranking in search engines.

Other examples canvassed include some of our old support related content, and comments / suggestions that don't advocate best practice, or are not relevant to currently supported versions of Drupal.

As for being more specific about the quantity - I can't really do that, it's hypothetical. The reason for asking for this feature is so that content moderators and editors don't have to rely on someone hard coding it. Once this is in place it's likely it will get used, and we can create guidelines for when/how it should and should not be used.

So I'd say a permissioned field is the way to go here. Thanks Drumm!

greggles’s picture

From a technical perspective I think a hardcoded list of nids or paths would be fine for now. Whenever gets the done ASAP and is reasonably extensible. to cover other kinds of pages makes sense to me.

From a policy perspective, I feel a bit unclear about whether this is really appropriate.

greggles’s picture

I think it would be great to bring up questions like this in https://groups.drupal.org/community which is a group for general discussion of community policies in "community" sites (i.e. beyond drupal.org).

kattekrab’s picture

Yes - we are in the process of drafting policy around this issue and around the potential use of a feature allowing it to be used in future. When ready it will be posted to https://drupal.org/project/issues/drupal-cwg and cross-posted to http://groups.drupal.org/governance (cross-posted to Drupal Planet, @drupal, etc.) for community feedback/discussion, and yes the community group on g.d.o also looks like a good spot!

The CWG decided to act first in this instance because the issue is actively causing a community member ongoing damage and has been for a long time, and then draft policy around the bigger issue.

opdavies’s picture

Assigned: Unassigned » opdavies
opdavies’s picture

I'm investigating using Metatag module for this as it provides the options to add nofollow links on a node by node basis, as well as preventing the node from being indexed at all using the meta robots tag.

It's not a permissioned field, but it does add its own permission to administer metatag module that we could assign to certain user roles, as well as providing default settings per content type, if needed.

I've installed it onto my dev site and configured it, but the resulting tag isn't showing after updating the node. I'm getting Varnish headers returned from the HTTP request so I think that Varnish is still presenting the cached version. I've tried switching themes and the result is the same, so it's not an issue with Bluecheese. I'm going to speak with Rudy later and confirm or deny this.

The "nofollow" option appears to already be added to links by the configuration of the Filtered HTML input format.

opdavies’s picture

This appears to not be a caching issue, and I've managed to get tags displaying for a book node, but still not for a forum node. I'm going to double-check the module's configuration, and failing that, looking into anything that could be either preventing it from displaying or overwriting the output.

opdavies’s picture

I'm going to double-check the module's configuration, and failing that, looking into anything that could be either preventing it from displaying or overwriting the output.

This was an issue caused by metatag and comment_fragment modules conflicting. A more detailed description and a patch can be found at https://drupal.org/node/2265447.

opdavies’s picture

Issue summary: View changes
opdavies’s picture

Issue summary: View changes
drumm’s picture

Status: Active » Fixed

Now deployed on Drupal.org. The permissions are the default admin-only. If needed, the content working group members should apply to be admins (always want the formal process so we have a bit of a paper trail, even if you are a shoe-in). Or, a separate issue to set up an existing role with new access, or a new role.

drumm’s picture

I had to disable the metatag module because it caused #2266021: Wrong title on Your issues page.

drumm’s picture

Status: Fixed » Active
opdavies’s picture

I can't replicate this on dev. I've got two browsers open, one logged in as opdavies and the other as Dries, and the titles on both fine.

The issue does occur on staging, however. Is there anything different in terms of caching, module configuration etc there that could be causing it?

drumm’s picture

The underlying problem is reproducible on dev:

SELECT * FROM cache_metatag WHERE cid = 'output:global:en:200:http:opdavies-drupal.redesign.devdrupal.org:/:project/issues/user' contains Issues for drumm.

This is cached toward the end of metatag_page_build(). This does have a cache hit for multiple users on dev. We can either

  • Fix or work around this bug.
  • Try out $conf['metatag_load_all_pages'] = FALSE; (I think I prefer this solution, at least from what I know now.)
  • Disable part or all of the global metatag config.

I'm not sure exactly why this doesn't completely manifest itself on dev. Dev does have various cache settings turned down, since they can get in the way of development.

opdavies’s picture

Try out $conf['metatag_load_all_pages'] = FALSE; (I think I prefer this solution, at least from what I know now.)

Yes, I think that would be my preferred option too.

drumm’s picture

Status: Active » Fixed

Now deployed again.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.