Gobernanza de contenido para equipos grandes: Escalando WordPress sin caos

Cuando eres un blogger solitario, simplemente haces clic en "Publicar". Cuando eres un editor de medios con 50 editores, 5 oficiales de cumplimiento legal y 3 especialistas SEO, hacer clic en "Publicar" sin un proceso definido es una responsabilidad empresarial.

En 2026, WordPress empresarial se trata menos de escribir código y más de diseñar flujos de trabajo de gobernanza que protejan la marca sin frenar a quienes crean contenido.

Esta guía describe cómo estructurar un entorno WordPress en el que quien escribe produce y quien aprueba controla: roles, estados, notas de revisión, bloqueo del editor, staging, control de plugins, revisión multilingüe y registro de auditoría.

Conoce más sobre el desarrollo WordPress profesional en WPPoland.

#Qué puede hacer cada rol predeterminado de WordPress

La documentación de usuario de WordPress enumera seis roles predeterminados: Super administrador, Administrador, Editor, Autor, Colaborador y Suscriptor. Las listas de capacidades que hay detrás deciden más de lo que sugieren los nombres.

Tres detalles importan para la gobernanza. Un Autor también tiene delete_published_posts, así que quien escribe con ese rol puede retirar su propio artículo publicado sin que nadie lo apruebe. Un Colaborador solo tiene read, edit_posts y delete_posts, por eso no puede adjuntar imágenes. En Multisite, instalar y actualizar plugins y temas, gestionar usuarios y unfiltered_html quedan reservados al Super administrador, mientras que en un sitio único los tiene el Administrador.

#Quién puede publicar HTML sin filtrar en WordPress

unfiltered_html permite guardar marcado que WordPress normalmente limpiaría, incluidas etiquetas script. En un sitio único lo tienen el Administrador y el Editor. En Multisite, solo el Super administrador. Para una redacción significa que cada Editor de una instalación única puede meter código en bruto en una página publicada. Si tus editores no lo necesitan, quita esa capacidad al rol Editor y anota la decisión junto a la matriz de roles.

La misma documentación indica que unfiltered_upload no se concede a ningún rol por defecto, ni siquiera al Super administrador. Solo se activa al definir ALLOW_UNFILTERED_UPLOADS en wp-config.php. Mantén esa constante fuera de producción salvo que un flujo concreto la necesite.

#Roles personalizados de WordPress para equipos editoriales

Los roles predeterminados de WordPress se pensaron para blogs pequeños, no para organizaciones con decenas de personas involucradas en el proceso de publicación.

#Límites de los roles predeterminados de WordPress

• Administrador: Tiene los “códigos nucleares”. Puede eliminar el sitio completo.
• Editor: Puede publicar cualquier cosa, incluyendo eliminar el trabajo de otras personas.
• Autor: Puede publicar su propio trabajo instantáneamente sin revisión.

El problema de gobernanza: Probablemente tienes un “Escritor Júnior” que debería escribir pero no publicar. Tienes un “Miembro del Equipo Legal” que debería aprobar pero no editar. Tienes un “Especialista SEO” que debería optimizar metadatos pero no alterar el contenido. Los roles predeterminados no pueden acomodar estas distinciones críticas.

#Cómo crear roles personalizados con capacidades granulares

Usando herramientas como Members o PublishPress Capabilities, o código propio, definimos roles personalizados que reflejan la estructura organizacional:

1. Colaborador+: Puede subir medios (lo que el Colaborador por defecto no puede, porque le falta upload_files) pero no puede publicar. Ideal para escritores freelance externos.

2. Aprobador SEO: Puede editar meta tags y leer contenido, pero no puede cambiar el contenido del post. Perfecto para especialistas SEO que optimizan sin alterar el mensaje.

3. Gestor de Layout: Puede editar Patrones Sincronizados pero no publicaciones individuales. Esencial para el equipo de diseño que mantiene componentes de marca.

4. Revisor Legal: Puede leer todo el contenido y agregar notas de revisión, pero solo puede cambiar el estado a “Aprobado por Legal”. No tiene capacidad de edición de contenido.

5. Editor Regional: Puede editar y publicar contenido solo dentro de categorías o sitios asignados a su región. No tiene acceso a contenido de otras regiones.

En el código, comprueba capacidades (current_user_can( 'publish_posts' )) en lugar de nombres de rol. Un nombre de rol no dice nada de lo que un plugin o una migración posterior le añadió, y la comprobación de capacidad hace exactamente la pregunta que importa.

#Cómo añadir un rol personalizado con código

El manual de plugins explica que WordPress guarda los roles y sus capacidades en la tabla de opciones, bajo la clave user_roles. Ese detalle condiciona cómo se escribe la migración:

function wppoland_register_writer_role() {
	if ( get_role( 'newsroom_writer' ) ) {
		return;
	}
	add_role(
		'newsroom_writer',
		'Redactor',
		array(
			'read'         => true,
			'edit_posts'   => true,
			'upload_files' => true,
		)
	);
}
add_action( 'init', 'wppoland_register_writer_role' );

Tras la primera llamada, el rol queda en la base de datos y las siguientes llamadas a add_role() no hacen nada, aunque cambie la lista de capacidades. Para cambiar el conjunto de golpe, el manual indica eliminar el rol con remove_role() y volver a añadirlo, y hacerlo solo cuando las capacidades guardadas difieran de las esperadas, porque registrarlo sin condición degrada mucho el rendimiento. Las capacidades sueltas se añaden a un rol existente con get_role() y add_cap(). El manual también desaconseja eliminar los roles Administrador y Super administrador, y recuerda actualizar default_role si se elimina Suscriptor.

Guarda las definiciones de roles en control de versiones y aplica los cambios de capacidades con una migración controlada, no haciendo clic en producción.

#Matriz de permisos por rol en WordPress

#Flujo de aprobación editorial en WordPress

Necesitas forzar una progresión lineal del contenido. Cada pieza de contenido debe pasar por etapas definidas antes de llegar al público, y cada etapa tiene un responsable claro.

#Qué estados de entrada trae WordPress de serie

La documentación sobre estados de entrada enumera ocho estados integrados: publish, future, draft, pending, private, trash, auto-draft e inherit. Cuando un usuario tiene edit_posts pero no publish_posts, el editor muestra el botón “Enviar para revisión” en lugar del de publicar, y la entrada pasa a pending. Es la única puerta de revisión que el núcleo ofrece sin código.

Para más etapas, register_post_status() añade estados como seo_review o legal_review. La misma página de documentación advierte que esa función no añade el estado registrado a las pantallas de administración (ticket de Trac #12706), así que un estado propio necesita su propia interfaz en el editor antes de que el equipo pueda usarlo. El hook transition_post_status se dispara en cada cambio de estado y sirve para avisar al siguiente revisor, bloquear saltos no permitidos (por ejemplo, de borrador directo a publish) y escribir una fila de auditoría con usuario, estado anterior, estado nuevo y hora.

#Etapas del flujo de aprobación editorial

• Etapa 1: Borrador: El escritor trabaja en el contenido, dentro de los patrones de marca aprobados.
• Etapa 2: En revisión: Se avisa al Editor Jefe. El contenido se revisa por calidad, coherencia de mensaje y alineación con la estrategia de contenido.
• Etapa 3: Revisión SEO: La puntuación del plugin SEO debe superar el umbral que fije el equipo. Se verifican meta tags, enlaces internos, schema markup y palabras clave.
• Etapa 4: Legal/Cumplimiento: Se revisan afirmaciones, fuentes citadas, disclaimers requeridos y cumplimiento regulatorio.
• Etapa 5: Programado: Bloqueado para publicación. Se asigna fecha y hora dentro del calendario editorial.

#PublishPress Planner y Oasis Workflow para flujos editoriales

• PublishPress Planner: Según su ficha en WordPress.org, añade un calendario de contenidos, una vista general del contenido, un tablero Kanban y notificaciones. Permite ver todo el pipeline en el calendario e identificar cuellos de botella y huecos.

• Oasis Workflow: Su ficha describe tareas de asignación, revisión y publicación, enrutado por rol y una bandeja donde cada usuario firma sus tareas. Así un post no avanza a publicación hasta que el revisor asignado firma su etapa.

#Notificaciones automáticas entre etapas de aprobación

1. El escritor crea el borrador y el sistema avisa al editor de que hay un borrador pendiente de revisión.
2. El editor revisa y aprueba, y el sistema avisa al equipo SEO.
3. SEO optimiza y aprueba, y el sistema avisa al equipo legal.
4. Legal revisa y aprueba, y el contenido se programa.
5. El escritor recibe la fecha de publicación de su artículo.

#Cómo medir la eficiencia del flujo editorial

Mide la eficiencia de tu pipeline editorial:

• Tiempo de borrador a publicación: fija un objetivo interno y compáralo cada mes
• Tasa de rechazo por etapa: identificar dónde se generan más revisiones
• Cuellos de botella: qué etapa acumula más contenido pendiente
• Productividad por escritor: artículos publicados por mes por persona

#Cómo revisar borradores con notas en el editor de bloques

WordPress 6.9 introdujo las Notas (Notes) en el editor de bloques, y la documentación de usuario indica que las funciones más avanzadas llegaron en WordPress 7.1. En la versión actual, un revisor puede fijar una nota a un bloque entero o a un fragmento de texto seleccionado, abrir hilos separados en el mismo bloque, mencionar a otro usuario con @, responder y marcar un hilo como resuelto cuando el asunto queda cerrado. Las notas solo se ven en el editor y nunca en el contenido publicado.

Los permisos siguen al derecho de edición. Administradores y Editores ven y añaden notas en todas las entradas. Autores y Colaboradores, en sus propias entradas. Los Suscriptores no las ven. Por defecto WordPress envía un correo al autor de la entrada cuando otra persona deja una nota y al usuario mencionado; los ajustes de comentarios controlan ese aviso. Las notas funcionan en los editores de entradas y páginas, no en el editor del sitio, y un tipo de contenido personalizado necesita que su tema o plugin añada el soporte.

Para la gobernanza, esto saca los comentarios de revisión de los chats y los lleva a la propia entrada. Un revisor legal marca la frase exacta que necesita un disclaimer, menciona al editor de sección y resuelve el hilo tras la corrección. Las notas resueltas quedan en el historial de la entrada como referencia. Las notas no sustituyen a una puerta de estado: registran la conversación, mientras publish_posts sigue decidiendo quién publica.

#Cómo bloquear bloques y colores en Gutenberg

El Editor de Bloques es poderoso. Si das a un editor un lienzo en blanco, podría usar colores fuera de marca o romper la estructura de una página. La gobernanza del editor mantiene la integridad visual. El manual del editor agrupa estos controles en curating the editor experience.

#Paleta fija, bloqueo de bloques y bloques permitidos por rol

1. Deshabilitar colores: En theme.json, deshabilita el selector de color personalizado y deja solo la paleta de marca.

{
  "settings": {
    "color": {
      "custom": false,
      "customGradient": false,
      "defaultPalette": false,
      "palette": [
        { "slug": "brand-primary", "color": "#1a1a2e", "name": "Primario" },
        { "slug": "brand-secondary", "color": "#16213e", "name": "Secundario" }
      ]
    }
  }
}

2. Bloqueo de bloques: Usa lock: { move: true, remove: true }. Crea un patrón “Callout de Producto” donde solo puedan escribir en el encabezado y el botón, pero no puedan mover el botón ni eliminar ninguna sección. Desde WordPress 6.1, "templateLock":"contentOnly" en Group, Cover o Columns oculta las herramientas de diseño y deja editables el texto y las imágenes.

3. Bloques permitidos: Desregistra los bloques que no quieres en el vocabulario de la redacción y ocúltalos del insertor.

// Restringir bloques disponibles por rol
function restrict_blocks_by_role( $allowed_blocks ) {
    $user = wp_get_current_user();

    if ( in_array( 'contributor_plus', $user->roles, true ) ) {
        return array(
            'core/heading',
            'core/paragraph',
            'core/image',
            'core/list',
            'core/quote',
        );
    }

    return $allowed_blocks;
}
add_filter( 'allowed_block_types_all', 'restrict_blocks_by_role' );

#Quién puede desbloquear bloques en Gutenberg

La página de la Block Locking API incluye una advertencia clave: por defecto, los usuarios con acceso de edición pueden desbloquear los bloques que el autor del tema bloqueó. Un patrón bloqueado sin más es una sugerencia, no un control. El filtro block_editor_settings_all cierra ese hueco; el ejemplo del manual vincula el derecho a la capacidad edit_theme_options:

add_filter( 'block_editor_settings_all', function( $settings ) {
	$settings['canLockBlocks'] = current_user_can( 'edit_theme_options' );
	return $settings;
} );

La misma familia de filtros permite poner codeEditingEnabled en false. El manual lo recomienda donde editar el marcado de bloques en bruto puede romper el contenido; añade una comprobación de capacidad si solo algunos usuarios deben perder ese acceso. Prueba cada control con una cuenta de nivel Editor: un Administrador ve otro editor y no notará las restricciones que querías imponer.

#Patrones de bloques preaprobados para editores

En lugar de páginas vacías, los editores comienzan con patrones pre-aprobados:

• Cada tipo de contenido tiene 2-3 patrones aprobados
• El editor selecciona un patrón y solo modifica el contenido
• La estructura, tipografía y colores están bloqueados
• La consistencia visual se mantiene sin supervisión manual

#Cuándo usar un sitio de staging en WordPress

Separa el flujo de contenido de los cambios de infraestructura.

La redacción suele trabajar en producción con estados de borrador y revisión. Es normal en editores que necesitan la mediateca real y URL de vista previa auténticas. Las actualizaciones de tema, la instalación de plugins, los cambios de versión de PHP y los experimentos con roles y capacidades van primero a staging.

Un patrón que funciona:

1. Staging replica el código de producción y una copia reciente del contenido.
2. Los cambios de roles y capacidades se prueban con usuarios de prueba que corresponden a puestos reales.
3. Los patrones de bloques, los bloqueos de paleta en theme.json y las listas de bloques permitidos se verifican con una cuenta de nivel Editor, no como Administrador.
4. Solo tras la aprobación se promueve el paquete de código a producción.

Los enlaces de vista previa y las URL de staging no deben filtrar textos legales sin publicar a la web abierta. Protege staging con autenticación. Trata la “vista previa compartible” como una capacidad deliberada, no como un subdirectorio público.

El staging de contenido (borradores) y el staging de entorno (código) resuelven fallos distintos. Mezclarlos es como una actualización de plugin llega un viernes por la tarde mientras tres personas están a mitad de revisión en el editor de bloques.

#Política de actualización de plugins para equipos grandes

Los plugins cambian capacidades, pantallas de administración, tareas cron y la salida del frontend. En un equipo grande, las actualizaciones sin control son un agujero de gobernanza tan grande como un botón de publicar sin vigilancia.

Escribe una política de cambios que el equipo de plataforma pueda hacer cumplir:

• Ninguna instalación de plugins en producción sin un ticket que nombre riesgo, rollback y responsable.
• Las actualizaciones llegan primero a staging; prueba el inicio de sesión, la carga del editor, el checkout (si hay comercio) y los estados personalizados de los que dependes.
• Mejor menos plugins con responsables claros que una larga cola de “quizá lo necesitemos”.
• Desactiva la edición de archivos de temas y plugins en el admin (DISALLOW_FILE_EDIT) para que nadie con edit_plugins pueda parchear en vivo el mapa de capacidades o el flujo. La documentación de wp-config describe además DISALLOW_FILE_MODS, que también bloquea instalar y actualizar plugins y temas desde el admin e incluye por sí solo la prohibición del editor de archivos. Úsalo cuando las actualizaciones lleguen solo por tu pipeline de despliegue.
• Registra activaciones, desactivaciones y actualizaciones en el mismo rastro de auditoría que las ediciones de entradas.

Cuando un plugin registra sus propias capacidades, documéntalas junto a la matriz de roles. Un plugin de seguridad o de SEO que concede capacidades extra al Editor puede deshacer en silencio meses de diseño de roles.

#Flujo de aprobación de traducciones en WordPress multilingüe

Un WordPress multilingüe multiplica cada decisión de gobernanza por el número de idiomas.

Si tienes un sitio por idioma, replica la matriz de roles en cada uno y mantén sincronizadas las migraciones de capacidades. Quien publica en el sitio español no debería ser automáticamente quien publica en el alemán, salvo que sea una decisión explícita.

Si tienes un único sitio con una capa de traducción (carpetas por idioma, conexiones entre sitios o un plugin de traducción), define quién es responsable del idioma de origen y quién de cada traducción. Aprobar el origen no es aprobar la traducción. Un revisor nativo debe firmar antes de que ese idioma salga en vivo.

Reglas prácticas que aguantan la carga:

• Asigna revisores por idioma como usuarios con nombre, no como un acceso compartido.
• Mantén visible el estado de la traducción junto a la entrada de origen, para que quien publica vea qué idiomas están listos.
• No publiques traducciones automáticamente al publicar el origen, salvo que el mercado acepte ese riesgo.
• Alinea la política de slugs y canonical por idioma, para que las listas de revisión incluyan URL y hreflang, no solo el cuerpo del texto.
• Guarda el glosario y la lista de afirmaciones prohibidas donde el revisor pueda abrirlos al editar, sobre todo en sectores regulados.

Las zonas horarias importan. Un flujo que avisa a un revisor legal a las 02:00 hora local acabará esquivado. Fija plazos de revisión por idioma y construya los avisos en torno a esas ventanas.

#Registro de actividad en WordPress con WP Activity Log

El cumplimiento requiere responsabilidad. Si un disclaimer desaparece de una página financiera regulada, necesitas saber quién lo eliminó y cuándo.

#Qué registra WP Activity Log y qué alertas envía

WP Activity Log (anteriormente WP Security Audit Log) es un plugin de registro de auditoría para WordPress.

Granularidad: según su ficha en WordPress.org, registra en entradas, páginas y tipos de contenido personalizados los cambios de estado, de contenido, de título, de URL y de campos personalizados y otros metadatos, además de la instalación, activación, desactivación, desinstalación y actualización de plugins y temas.

Alertas: Configura avisos cuando se desactive un plugin o se cree un usuario con privilegios de Administrador. Estas alertas permiten responder enseguida a cambios no autorizados.

#Qué registran las revisiones de WordPress

El núcleo ya guarda parte de este historial. Según la documentación de revisiones, WordPress guarda una revisión por cada borrador guardado o actualización publicada y, por defecto, sigue los cambios de título, autor, contenido y extracto. Las revisiones se guardan en la tabla posts como hijas de la entrada. Cada usuario tiene como máximo un autoguardado por entrada, y los autoguardados nunca sobrescriben el contenido publicado. WordPress 7.0 añadió una nueva pantalla de revisiones que marca los bloques añadidos, eliminados y modificados; la pantalla clásica, con su modo de comparar dos revisiones cualesquiera, sigue disponible.

La trampa para la gobernanza es la constante WP_POST_REVISIONS. Con un número, WordPress guarda esa cantidad de revisiones por entrada y borra automáticamente las más antiguas al volver a actualizarla. Con false o 0, no guarda ninguna salvo el autoguardado. Un límite bajo elegido para ahorrar espacio acorta en silencio el historial del que dependen los revisores, y no hay pantalla de administración para gestionar revisiones. Las revisiones tampoco registran cambios de estado, de roles ni eventos de plugins, así que complementan un registro de actividad y no lo sustituyen.

#Requisitos de auditoría por industria

#Cuánto tiempo y dónde guardar los registros de auditoría

Los registros de auditoría requieren políticas de retención claras:

• Retención: fija el plazo según tu política interna y las normas de tu sector; no des por buena la retención por defecto del plugin
• Almacenamiento externo: exportar registros a sistemas SIEM como Splunk o ELK si tu equipo de seguridad lo exige
• Inmutabilidad: nadie debe poder modificar ni eliminar registros sin dejar rastro
• Acceso controlado: solo personal autorizado puede consultar los registros

#Cómo revisar contenido desactualizado en WordPress

El contenido se deteriora. Un post de 2019 sobre “Mejores teléfonos de 2019” ahora está dañando tu SEO (“Decadencia de Contenido”). La gestión del ciclo de vida mantiene la autoridad del sitio.

#Fechas de revisión, avisos y archivado automático

1. Fechas de revisión: Establece un campo personalizado de “Fecha de Revisión” en contenido evergreen (por ejemplo, cada 6 meses). El sistema rastrea el contenido que necesita actualización.

2. Notificaciones: Cuando la fecha llega, WordPress envía un correo al autor original preguntando si el contenido sigue siendo preciso. Si no hay respuesta en 7 días, se escala al editor jefe.

3. Archivado: Automatiza la despublicación de eventos temporales (webinars) 24 horas después de que terminen. No automatices el borrado silencioso de páginas reguladas.

#Cada cuánto revisar cada tipo de contenido

#Señales automáticas de salud del contenido

• Frescura: fecha de la última actualización
• Rendimiento: tendencia del tráfico orgánico
• Interacción: tasa de rebote y tiempo en página
• Precisión: enlaces rotos o información desactualizada
• SEO: si la puntuación de optimización sigue siendo competitiva

#Cómo publicar contenido aprobado en web, app y newsletter

El contenido no solo se publica en el sitio web. La gobernanza debe extenderse a todos los canales donde aparece.

#Canales a los que se distribuye un artículo aprobado

Cuando un artículo se aprueba, puede distribuirse a la vez a:

• Sitio web principal
• App móvil (vía API)
• Newsletter (integración con Mautic o Mailchimp)
• Redes sociales (resúmenes a partir de plantillas aprobadas)
• Sitios regionales (vía Multisite broadcast)

#Cómo mantener el mismo mensaje en cada canal

Cada canal tiene sus propias restricciones, pero el mensaje central debe ser consistente:

• Plantillas de redes sociales preaprobadas
• Guía de tono y voz por canal
• Aprobación automática si el contenido sigue la plantilla aprobada
• Revisión manual para el contenido que se desvíe

#Caso de estudio de flujo editorial en un portal financiero

Trabajo con un portal de asesoramiento financiero en el que cada palabra debía cumplir la normativa financiera y pasar revisión legal antes de publicarse.

#Problema de cumplimiento normativo

• Cada afirmación publicada tenía que ser conforme con la regulación financiera
• Muchos escritores generaban contenido a la vez
• El equipo legal no podía revisarlo todo a mano a tiempo
• Publicar información incorrecta habría sido caro y dañino para la reputación

#Configuración de roles y panel de cumplimiento

• Solo unas pocas personas tenían la capacidad de publicar
• Los escritores trabajaban en estado borrador
• Un panel de cumplimiento personalizado en WP Admin mostraba al equipo legal solo las entradas que esperaban su revisión
• Etiquetas automáticas enrutaban el contenido sobre productos financieros concretos al revisor especializado

#Resultados tras el cambio de flujo

Los cuellos de botella se redujeron. Los escritores escribían, los abogados revisaban y no hubo publicaciones accidentales. El flujo pasó a medirse por estado y longitud de cola.

#Plugins de WordPress para roles, flujos y auditoría

Los precios cambian; consulta las páginas públicas de cada proveedor. Lo que importa es la función:

#Qué plugins usar según el tamaño del equipo

Equipo pequeño (5-15 editores):

• Members + PublishPress Planner
• Flujo simple de 3 etapas

Equipo mediano (15-50 editores):

• PublishPress Capabilities + Planner + WP Activity Log
• Flujo de 5 etapas con aprobaciones

Equipo grande (50+ editores):

• Stack completo + integraciones personalizadas
• Flujo de 7+ etapas con enrutado automático
• Panel personalizado por rol
• Integración con Slack o Teams para notificaciones

#Qué incluye un marco de gobernanza de contenido en WordPress

Una configuración duradera son cinco capas que se refuerzan entre sí:

1. Capacidades y roles personalizados asignados a puestos reales.
2. Estados personalizados, reglas de transición y notas en el editor que fijan el orden de revisión.
3. Staging para el código y control de cambios para los plugins.
4. Revisión por idioma para la salida multilingüe.
5. Registros de auditoría, revisiones y fechas de revisión para rendir cuentas después de publicar.

Si falta una capa, las demás se convierten en parches. Sin roles, los flujos parecen opcionales. Sin staging, una actualización de plugin rompe la interfaz del flujo. Sin revisión multilingüe, un idioma publica afirmaciones que otro rechazó.

La gobernanza no es burocracia. Es la red de seguridad que permite trabajar rápido. Al codificar tus operaciones en el propio WordPress, desaparece la pregunta constante de si alguien consultó a legal, y el equipo puede centrarse en producir contenido de calidad.

¿Luchando con el caos editorial? WPPoland construye flujos de gobernanza personalizados para equipos de contenido empresariales.

#Recursos relacionados

• Desarrollo WordPress profesional - Arquitectura empresarial de WordPress
• Mantenimiento WordPress - Gestión continua de contenido y sistemas
• Auditoría de seguridad WordPress - Seguridad y cumplimiento
• Rediseño WordPress - Modernización de flujos editoriales
• SEO, GEO y AEO WordPress - Optimización de contenido para búsqueda