WordPress wp_robots Example: Set Page-Level Robots Directives Safely

Last reviewed: May 5, 2026

Search directives are easy to over-control in WordPress. Teams often hardcode a robots meta tag into templates, then forget that WordPress already has a centralized robots system that can be filtered per request. wp_robots() and the wp_robots filter are the safer path when a site needs page-level indexing rules without scattering meta logic across theme files.

This guide shows how to add a focused robots directive for a specific request pattern and how to keep those rules narrow so the rest of the site stays indexable.

Add a robots directive through the centralized filter

<?php
add_filter( 'wp_robots', 'vulnwp_noindex_private_tool_page' );

function vulnwp_noindex_private_tool_page( $robots ) {
	if ( ! is_page( 'internal-status-tool' ) ) {
		return $robots;
	}

	$robots['noindex']  = true;
	$robots['nofollow'] = true;

	return $robots;
}

This keeps the decision inside WordPress’ own robots pipeline instead of printing a manual meta tag that can drift from other SEO behavior.

Scope the rule to the exact page or condition

The real risk with robots directives is not the syntax. It is overly broad targeting. If the callback attaches noindex too loosely, category archives, paginated content, or the blog index can disappear from search because the condition was wider than intended.

Do not mix robots meta with unrelated template output

Template files should not become the long-term source of truth for crawl directives when WordPress already exposes a filter for them. Centralized logic is easier to audit and easier to remove when indexing rules change.

Remember that robots meta is page output, not authentication

A noindex directive helps search engines, but it does not secure private content. If a route should not be public, protect the route itself rather than relying on crawl hints.

Common mistakes

• Adding a manual robots meta tag in several templates. This creates duplication and drift.
• Applying noindex to a whole content area accidentally. Broad conditionals are the usual cause.
• Treating robots directives as access control. They are not a security control.
• Forgetting to review the output on the final rendered page. Filters should be validated in production-like HTML, not only in PHP.

Production checklist

• Use the wp_robots filter instead of scattered template meta tags.
• Keep the conditional as narrow as possible.
• Review rendered HTML on the final page before rollout.
• Use route protection or authentication for truly private content.
• Re-check Search Console behavior after changing crawl directives.

Related reading

Pair this with the REST API exposure checklist when the page surfaces integration data, and with the template_redirect guide if the route should be restricted instead of merely discouraged from indexing.

References and further reading

• WordPress Code Reference: wp_robots()
• WordPress Code Reference: wp_robots_sensitive_page()
• WordPress Code Reference: wp_robots filter