Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
- Download the 7.x-1.x-dev version of the Metatag module
- Enable metatag and metatag_ui.
- Go to admin/people/permissions#module-metatag and assign permissions.
- 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:
- Edit a node.
- Scroll down to the "Meta tags" vertical tab.
- Override any of the default values. The noindex and nofollow options are within the Advanced fieldset.
- Save the node.
Comment | File | Size | Author |
---|---|---|---|
#8 | Screen Shot 2014-05-08 at 13.43.37.png | 336.5 KB | opdavies |
#8 | Screen Shot 2014-05-08 at 13.06.26.png | 270.01 KB | opdavies |
Comments
Comment #1
drummHow 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.
Comment #2
gregglesCan 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!).
Comment #3
kattekrab CreditAttribution: kattekrab commented@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!
Comment #4
gregglesFrom 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.
Comment #5
gregglesI 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).
Comment #6
kattekrab CreditAttribution: kattekrab commentedYes - 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.
Comment #7
opdaviesComment #8
opdaviesI'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.
Comment #9
opdaviesThis 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.
Comment #10
opdaviesThis 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.
Comment #11
opdaviesComment #12
opdaviesComment #13
drummNow 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.
Comment #14
drummI had to disable the metatag module because it caused #2266021: Wrong title on Your issues page.
Comment #15
drumm#2101301: Cannot get page title to work on Views pages may be the underlying bug.
Comment #16
opdaviesI 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?
Comment #17
drummThe 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'
containsIssues 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$conf['metatag_load_all_pages'] = FALSE;
(I think I prefer this solution, at least from what I know now.)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.
Comment #18
opdaviesYes, I think that would be my preferred option too.
Comment #19
drummNow deployed again.