WordPress template_redirect Example: Restrict a Sensitive Front-End Route

Last reviewed: April 24, 2026

The template_redirect hook is powerful because it runs after WordPress knows what the request is, but before the final template is loaded. That makes it a good place for access control, conditional redirects, gated content, and canonical routing decisions that depend on the resolved query.

This guide shows a safe pattern for protecting a sensitive front-end route behind authentication without creating redirect loops or breaking unrelated templates.

Protect a request after WordPress resolves it

<?php
add_action( 'template_redirect', 'vulnwp_protect_private_downloads' );

function vulnwp_protect_private_downloads() {
	if ( ! is_page( 'private-downloads' ) ) {
		return;
	}

	if ( is_user_logged_in() ) {
		return;
	}

	$target = add_query_arg(
		array(
			'redirect_to' => rawurlencode( home_url( '/private-downloads/' ) ),
		),
		wp_login_url()
	);

	wp_safe_redirect( $target, 302, 'VulnWP Access Gate' );
	exit;
}

The guard checks the exact request type first. That keeps the hook cheap for every other page on the site.

Avoid redirect loops

Redirect logic should always answer one question early: can this request already access the destination safely? If the login page, callback page, or allowed role pages are not excluded correctly, the site can trap users in a loop that is hard to debug under cache.

if ( is_page( 'private-downloads' ) && is_user_logged_in() ) {
	return;
}

if ( is_page( 'members-login' ) ) {
	return;
}

Keep exclusions obvious and close to the redirect rule. That makes future maintenance safer.

When template_redirect is appropriate

• Login gates for specific pages or archives.
• Redirecting deprecated public URLs to a supported location.
• Forcing a membership flow after query resolution.
• Blocking direct front-end access to content that should only be available to signed-in users.

Do not use template_redirect to swap templates manually when you really need a different template file. That is what the template hierarchy and template_include are for.

Production checklist

1. Check the exact condition first. The hook runs on many front-end requests.
2. Use wp_safe_redirect(). Redirects still need host validation.
3. Exit after a successful redirect.
4. Document exclusions. Login, callback, and allowed pages should be explicit.
5. Test with logged-in and logged-out users.

Common mistakes

• Using a broad conditional like ! is_user_logged_in() with no request guard. That can redirect the whole site.
• No loop protection. Redirect chains can lock out real users.
• Using template_redirect to include PHP files manually. That is the wrong abstraction.
• Forgetting query caching or CDN behavior. Test authenticated and anonymous responses separately.
• Building redirects from raw request input. Use trusted destinations only.

Related reading

If the redirect destination comes from request parameters, use the wp_safe_redirect article. For choosing the right template after the request resolves, pair this with the template hierarchy guide.

References and further reading

• WordPress Code Reference: template_redirect
• WordPress Code Reference: is_page()
• WordPress Code Reference: wp_login_url()