Imagínelo: lanza un portal corporativo en WordPress, crea un tipo de contenido personalizado llamado «Equipamiento» y lo llena con documentación interna. Una semana después descubre que todas esas páginas están siendo indexadas por los motores de búsqueda y son visibles para cualquiera que pase por ahí. El acceso debería estar limitado a empleados autorizados, pero el suyo está abierto de par en par.

Las herramientas integradas de WordPress no permiten restringir de forma selectiva un tipo de contenido personalizado específico para usuarios no registrados. Existen roles y capacidades, pero la vinculación «los invitados no pueden ver el CPT X» no está disponible de serie. La solución consta de tres componentes: registro del CPT, configuración de roles y un plugin de restricción de lectura. El cuarto componente (opcional) es el inicio de sesión social para que los empleados no tengan que introducir una contraseña cada vez.

A continuación se desglosa paso a paso cada componente, con plugins y ajustes concretos. Todas las herramientas son gratuitas, están disponibles en el directorio oficial de WordPress.org y no requieren programación, aunque al final se cubre un enfoque puramente basado en código para quienes quieran evitar los plugins.

💡 Resumen rápido:

• Registre un tipo de contenido personalizado mediante Custom Post Type UI sin escribir una sola línea de código
• Cree un rol personalizado en PublishPress Capabilities y asígnelo a los empleados
• Restrinja el acceso de invitados al CPT usando el plugin WP Access Areas: los visitantes no autorizados son redirigidos a la página de inicio de sesión
• Opcionalmente, active el inicio de sesión social a través de Super Socializer para un acceso sin contraseña con cuenta de Google

Paso 1: Registrar un tipo de contenido personalizado

La primera etapa, y la más sencilla, es crear el CPT en sí. No necesita tocar functions.php para esto: el plugin Custom Post Type UI en WordPress.org proporciona una interfaz gráfica para registrar cualquier tipo de contenido y taxonomía.

La instalación es la habitual: «Plugins → Añadir nuevo», busque por nombre, active. Tras la activación, aparece un nuevo elemento de menú en la barra lateral: «CPT UI → Añadir/Editar tipos de contenido». Rellene los campos: slug (por ejemplo, equipment), nombres en plural y singular, etiquetas, y haga clic en «Añadir tipo de contenido».

El plugin llama a register_post_type() con los parámetros correctos automáticamente. No se requiere código manual: obtiene un tipo de contenido plenamente funcional con soporte de editor, archivos y API REST. Si más adelante necesita trasladar el registro a functions.php, CPT UI muestra el código PHP generado en la pestaña «Herramientas».

Durante el registro, preste atención a dos opciones críticas relacionadas con la seguridad. En el bloque «Ajustes» de CPT UI, hay una opción «Consultable públicamente» que determina si las entradas pueden abrirse mediante enlaces directos. Viene activada por defecto, e incluso después de restringir la lectura mediante un plugin, debe dejarla habilitada; de lo contrario, WordPress devolverá un error 404 en lugar de redirigir a la página de inicio de sesión, y los usuarios no entenderán qué ha ocurrido. El segundo parámetro, «Tiene archivo», habilita una página de archivo que lista todas las entradas del CPT. Si no necesita un archivo, desactívelo para que los motores de búsqueda no indexen una página de servicio con vistas previas de documentos restringidos.

Paso 2: Crear un rol personalizado

Simplemente restringir el acceso de invitados al CPT no basta: necesita un rol que sí tenga acceso. Por defecto, WordPress ofrece un conjunto fijo: Administrador, Editor, Autor, Colaborador, Suscriptor. Crearemos un nuevo rol usando el plugin PublishPress Capabilities (antes llamado Capability Manager Enhanced, mismo slug, misma funcionalidad, solo cambió el nombre).

Tras la activación, vaya a «Capabilities → Roles». En el lado derecho de la pantalla encontrará el bloque «Create New Role»:

Introduzca un nombre (por ejemplo, «Lector de Equipos»), seleccione un rol base del cual clonar (Suscriptor es lo mejor, por tener permisos mínimos) y haga clic en «Create». El nuevo rol ya existe y puede poblarlo con capacidades. Para leer un CPT, la combinación estándar de read + read_equipment (la capacidad registrada por CPT UI) es suficiente.

Asigne el rol creado a los empleados que necesiten acceso al contenido restringido. Después de esto, puede desactivar el plugin: los roles y capacidades permanecen en la base de datos de WordPress y no dependen de que PublishPress Capabilities esté activo.

Paso 3: Restringir el acceso de lectura al CPT

Este es el paso clave. El plugin WP Access Areas le permite definir con precisión quién puede leer, editar y comentar las publicaciones de cada tipo, hasta páginas individuales. Tiene unas modestas 400 instalaciones activas y no ha recibido actualizaciones mayores en un tiempo, pero para la tarea de «restringir el CPT a invitados» funciona de forma predecible y sin conflictos.

Tras la instalación, vaya a «Settings → Access Areas». En la sección «Default Behaviour», seleccione:

«If not logged in, redirect to login. Otherwise redirect to the fallback page.»

Esta configuración envía a los usuarios no autorizados a wp-login.php cuando intentan abrir cualquier página protegida del CPT.

A continuación, aparece una tabla con todos los tipos de contenido registrados. Para su CPT, en la columna «Reading», seleccione «Logged in Users» del menú desplegable. Eso es todo: a partir de este momento, cualquier invitado que siga un enlace directo a una página del CPT será redirigido al formulario de inicio de sesión.

Nota importante: los ajustes realizados mediante la tabla solo se aplican a las nuevas publicaciones. Para las páginas ya creadas, debe establecer los permisos manualmente en la barra lateral del editor, donde aparece un bloque «Access Areas». Tras la configuración, asegúrese de verificar el resultado en el modo incógnito de su navegador: al abrir un enlace directo a una página protegida del CPT debería ver wp-login.php, no el contenido.

Alternativas a WP Access Areas si necesita una solución con mantenimiento más activo: PublishPress Permissions (la versión gratuita cubre CPT y roles) o ContentGate (un plugin ligero con reglas basadas en estado de inicio de sesión y roles).

Paso 4: Inicio de sesión social (opcional)

Introducir constantemente un usuario y contraseña en un portal corporativo genera una fricción innecesaria. La solución lógica: inicio de sesión con un clic mediante cuenta de Google. El plugin Super Socializer resuelve esta tarea, con más de 20.000 instalaciones activas y soporte para Google, Facebook, X (Twitter) y una docena de proveedores más.

Tras la activación, vaya a «Super Socializer → Social Login»:

Ajustes básicos: active la casilla «Disable user registration via social networks». Esto es importante para que solo las cuentas existentes puedan iniciar sesión a través de redes sociales, en lugar de crear otras nuevas. Luego seleccione el proveedor (Google) e introduzca el Client ID y el Client Secret. Dónde obtenerlos:

• Abra Google Cloud Console, cree un proyecto (o seleccione uno existente)
• En la sección «APIs & Services → Credentials», haga clic en «Create Credentials → OAuth client ID»
• El tipo de aplicación es Web application; en Authorized redirect URIs, pegue la URL de callback de los ajustes de Super Socializer
• Guarde para obtener su Client ID y Client Secret

Copie las claves en los campos del plugin:

Punto crítico: el campo Authorized redirect URIs no debe llevar barra diagonal al final, o recibirá un error redirect_uri_mismatch. Tras guardar, aparece un botón «Sign in with Google» en la página de inicio de sesión.

Importante: la versión original de este artículo (2020) describía la integración con Google+, que se cerró en abril de 2019. El Super Socializer moderno utiliza el protocolo estándar Google OAuth 2.0 a través de Google Identity Services. La interfaz de Google Cloud Console se ha actualizado desde entonces, pero la lógica de los pasos (proyecto → Credentials → OAuth client ID → redirect URI) sigue siendo la misma.

Enfoque alternativo: todo en código

Si los plugins adicionales no son deseables, la tarea puede resolverse en el functions.php del tema o en un tema hijo. El código registra el CPT, crea un rol y engancha una verificación de autorización a la plantilla:

1
// Registering a custom post type
2
function register_equipment_cpt() {
3
    register_post_type('equipment', [
4
        'labels'      => ['name' => 'Equipment', 'singular_name' => 'Equipment'],
5
        'public'      => true,
6
        'has_archive' => true,
7
        'supports'    => ['title', 'editor', 'thumbnail'],
8
        'capability_type' => 'equipment',
9
        'map_meta_cap' => true,
10
    ]);
11
}
12
add_action('init', 'register_equipment_cpt');
13
 
14
// Creating a role on theme activation
15
function add_equipment_reader_role() {
16
    add_role('equipment_reader', 'Equipment Reader', ['read' => true, 'read_equipment' => true]);
17
}
18
add_action('after_switch_theme', 'add_equipment_reader_role');
19
 
20
// Redirecting guests from CPT to login page
21
function restrict_equipment_to_logged_in() {
22
    if (is_singular('equipment') && !is_user_logged_in()) {
23
        wp_redirect(wp_login_url(get_permalink()));
24
        exit;
25
    }
26
}
27
add_action('template_redirect', 'restrict_equipment_to_logged_in');

Lo que hace este código: el primer bloque registra el CPT equipment con su propio tipo de capacidad (capability_type). El segundo bloque crea el rol Equipment Reader con permisos para leer este CPT cuando se activa el tema. El tercer bloque verifica la autorización en el gancho template_redirect y envía a los visitantes a wp-login.php.

La ventaja del enfoque con código: cero plugins adicionales, control total. La desventaja: el inicio de sesión social seguirá requiriendo un plugin (escribir la integración OAuth manualmente es lento e inseguro), y cada cambio en los roles implica editar código.

⁉️🤔 Preguntas frecuentes

¿Puedo restringir un CPT sin plugins, solo mediante funciones.php?

Sí. La combinación de register_post_type() + add_role() + el gancho template_redirect con una verificación is_user_logged_in() es una solución completamente funcional. El código se proporciona en la sección anterior. El inicio de sesión social sin un plugin es significativamente más difícil de implementar: la integración OAuth manual requiere manejar tokens, estado y seguridad.

¿Por qué WP Access Areas en lugar de un plugin más nuevo como ContentGate?

WP Access Areas es una herramienta minimalista para una tarea específica: «restringir un tipo de contenido a los visitantes». No trae consigo un constructor de reglas, editores visuales ni suscripciones. Si necesita una lógica más compleja (por ejemplo, diferentes niveles de acceso para distintos roles en el mismo CPT), use ContentGate o PublishPress Permissions, que se actualizan activamente. Para el escenario básico de esta guía, WP Access Areas es suficiente.

¿Qué debo hacer si los visitantes aún pueden ver las páginas del CPT después de la configuración?

Tres causas típicas. Primera: la configuración «Logged in Users» en la tabla de WP Access Areas solo se aplica a las nuevas publicaciones; para las páginas existentes, debe establecer los permisos manualmente a través de la barra lateral del editor. Segunda: un plugin de caché está sirviendo una versión almacenada en caché de la página a los visitantes; limpie la caché y configure exclusiones para el CPT protegido. Tercera: el CPT está registrado con 'publicly_queryable' => true y el slug entra en conflicto con una página pública; verifique las colisiones.

¿Puedo usar Super Socializer solo para el inicio de sesión, sin compartir ni comentarios?

Sí, los módulos del plugin son independientes. En la pestaña «Social Sharing», desmarque todas las casillas y los botones «Share» desaparecerán. En la pestaña «Social Commenting», desactive la integración. Deje solo «Social Login» con los proveedores que necesite. El plugin es ligero y desactivar los módulos innecesarios no afecta al rendimiento.

¿Es seguro desactivar PublishPress Capabilities después de crear un rol?

Sí. Los roles y capacidades de WordPress se almacenan en la tabla wp_options (la opción wp_user_roles) y no dependen del plugin que los creó. Después de desactivar PublishPress Capabilities, todos los roles creados y los permisos otorgados se conservan. Puede reactivar el plugin si necesita modificar los permisos más adelante.

¿Escribir código o quedarse con los plugins?

La elección entre plugins y functions.php se reduce a dos factores: la cantidad de CPT que se protegen y la frecuencia con la que cambian los permisos.

Si tiene un solo CPT (como el ejemplo del equipo), los roles son estables y está dispuesto a escribir 30 líneas de código una vez, el enfoque de functions.php es más limpio: no genera plugins, no depende de actualizaciones de terceros y es completamente transparente. Puede mantener Super Socializer para el inicio de sesión social, ya que resuelve una tarea concreta y no entra en conflicto con el código personalizado.

Si tiene varios CPT, los permisos se revisan con frecuencia o el sitio lo gestiona alguien que no es desarrollador, opte por la combinación de plugins. CPT UI + PublishPress Capabilities + WP Access Areas (o ContentGate) se pueden configurar desde el panel de administración en 15 minutos sin tocar código. Además, PublishPress Capabilities realiza automáticamente copias de seguridad de los roles con cada cambio, lo que permite revertir en dos clics.

En cualquier escenario, siga el principio: una herramienta para una tarea. No instale una potente solución todo en uno para una sola casilla de verificación, y no reinvente la rueda si un plugin existente hace exactamente lo mismo de forma más rápida y segura.

El control de versiones merece una consideración aparte. El código de functions.php reside en el repositorio del tema, los cambios se rastrean a través de Git y, al migrar el sitio, los roles se recrean automáticamente en el gancho after_switch_theme. El enfoque con plugins no ofrece esta transparencia: los roles se almacenan en la base de datos y, al desplegar una copia de staging o transferir a un nuevo dominio, deben recrearse manualmente o mediante un script de migración. Este factor a menudo resulta decisivo a favor del código para equipos que practican CI/CD y despliegue basado en Git.