Añádelo como fuente preferida en Google
Publicar contenido generado por IA es sencillo hasta que el flujo de trabajo se desvía de lo previsto. Por ejemplo, un cliente puede señalar que el contenido ha quedado obsoleto unas semanas después de su publicación y querer que se corrija de inmediato. Para ello, se necesitan los controles adecuados y una infraestructura de alojamiento adecuada. Sin ellos, es probable que haya retrasos.
En esta entrada se tratan las cuestiones de gestión que deberías plantear a tu equipo a la hora de publicar contenido generado por IA. Se centra en las frecuencias de publicación de gran volumen, que plantean sus propios retos.
El impacto de un mayor volumen de publicación con IA en tu despliegue de WordPress
Los LLM y la IA están lejos de ser infalibles. Hay muchas formas en las que un modelo puede introducir incoherencias en tu contenido:
- Alucinaciones o síntesis. Afirmaciones que parecen verosímiles, pero que son falsas, como citas y fuentes. Esto pasa, en parte, cuando la información sobre un tema es de mala calidad.
- Errores fácticos. Este tipo de alucinación confunde datos objetivos, como fechas y estadísticas.
- Simulación de éxito en las tareas. La entrada sobre medidas de seguridad para la IA del blog de Kinsta ofrece más detalles sobre cómo los LLM confirman erróneamente que una tarea se ha completado.
- Tono de voz y estilo de redacción. Los modelos se olvidan de las instrucciones debido (en parte) al recuento de tokens y a las ventanas de contexto.
Estos problemas editoriales también tienen que ver con tu alojamiento web. Por ejemplo, si la caché no se borra si apruebas un cambio de contenido en una entrada, la nueva versión no se aplicará. En los casos en los que necesites volver a una revisión anterior, un fallo en la copia de seguridad significa que no tendrás forma de revertir los cambios.
La proporción entre contenido generado por humanos y por IA es prácticamente igual. Como la IA genera contenido más rápido de lo que escriben los humanos, muchos blogs publican con más frecuencia. Además, la investigación de SE Ranking muestra que las actualizaciones principales (Core Updates) de Google modifican las posiciones en los resultados de búsqueda con mayor frecuencia. Esto es especialmente cierto en situaciones de «abuso de contenido a gran escala» (scaled content abuse): el término que usa Google para referirse a la publicación de grandes volúmenes de contenido sin editar.
Con una cadencia de publicación más alta y sin garantía de que haya menos errores, tienes que plantearte la producción y publicación de contenidos más como una tarea de despliegue de tu sitio web.
Por qué el staging debería formar parte de tu proceso de revisión de contenidos
El concepto de staging es una parte fundamental del desarrollo. Usar un entorno staging o un entorno aislado para probar el código es algo que se espera, por no decir un requisito, en muchos proyectos. Sin embargo, un flujo de trabajo de publicación no tiene las mismas expectativas.
Esto significa que, mientras que los cambios de desarrollo pasan por todo el flujo de trabajo de staging, la publicación se salta esa etapa y va directamente a producción. Si hay errores en ese contenido publicado e indexado, todos los que visiten el front end los verán.
La solución es organizar tu contenido en etapas, igual que haces con el código. Con un entorno idéntico al de producción, puedes editar la entrada y ver cómo quedaría el formato del contenido en el front end (entre otras cosas).
Además, podrás entender cómo interactúan otros elementos con tu entrada, como los elementos de la propia página o incluso otros plugins. El entorno staging te permite resolver estos problemas antes de publicar la entrada en producción.
El entorno staging de Kinsta
Cada sitio de Kinsta incluye un entorno staging gratuito, al que puedes acceder desde el menú desplegable de la parte superior del panel de control de MyKinsta. También hay entornos Premium si quieres más recursos y unas especificaciones más parecidas a las de tu entorno de producción:
En este caso, el envío selectivo es importante, sobre todo para las publicaciones en lote. Por ejemplo, al realizar staging con varias entradas, puedes enviar los archivos, la base de datos o ambos a la vez. Kinsta crea una copia de seguridad automática antes de que se realice cualquier acción. Esto te permite enviar contenido sin que se vean afectados los cambios de desarrollo.
Esto también funciona al revés. En una situación en la que se envían publicaciones o cambios directamente al entorno de producción, descargar los archivos y la base de datos al entorno staging hace que todo el pipeline esté sincronizado en cuestión de segundos.
Usar un sistema basado en permisos para limitar quién puede publicar contenido en el entorno de producción
Disponer de toda esta funcionalidad significa que los permisos de los usuarios deben ser fundamentales en tu flujo de trabajo. El entorno staging solo es útil si su uso es obligatorio. Los permisos te permiten hacer que el uso del entorno staging sea un paso obligatorio del proceso.
Hay unos roles de usuario de Kinsta específicos que te permiten aplicar este tipo de requisitos:
- Desarrollador del Sitio. Esto permite al usuario acceder a staging sin tener acceso a producción.
- Administrador del Sitio. Esto da acceso completo al sitio, incluyendo la posibilidad de publicar en entornos de producción.
Normalmente, asignas los roles de usuario de WordPress según el acceso que necesite cada persona. Sin embargo, asignar roles de usuario adicionales de Kinsta significa que conviertes el entorno staging en algo estructural.
Por ejemplo, los miembros del equipo que usen herramientas de IA generativa deberían tener el rol de Desarrollador del Sitio. Si lo combinas con un rol de usuario de WordPress como Editor o Autor, se limita el alcance de los privilegios. Además, esto significa que solo un Administrador del Sitio puede publicar el contenido en la web.
Por último, la seguridad básica de las cuentas de Kinsta te protege aún más. Por ejemplo, la autenticación de dos factores (2FA) garantiza que cualquier cambio provenga de una fuente verificada. Es una tranquilidad extra cuando tu checklist tiene un montón de cosas que tener en cuenta.
Cómo las copias de seguridad protegen tu contenido publicado de los errores relacionados con la IA
Los errores visuales en un sitio web son fáciles de detectar. Incluso los problemas técnicos, como los errores críticos del sitio, suelen ir acompañados de una página de bienvenida o de una notificación en el navegador. Sin embargo, las incoherencias en los datos, los errores que se pasan por alto, las estadísticas desactualizadas y las fichas de productos incorrectas suelen pasar desapercibidas.
Puede surgir un problema después de que guardes la página en la caché, los rastreadores la indexen y tus lectores compartan la entrada. Esos mismos visitantes también leen y asimilan el texto erróneo. Cuando el tráfico disminuye, el error en el texto de tus entradas queda a la vista de todos.
Cuando descubres un error en el contenido, tienes dos opciones disponibles:
- Editar la entrada y vaciar la caché. Esta es la forma más rápida si se trata de una sola página o de un error «aislado».
- Restaurar desde una copia de seguridad. Si el error afecta a varias entradas (por ejemplo, si tienes una serie temática que contiene la misma estadística incorrecta), volver a una copia de seguridad válida es más rápido que corregir cada entrada por separado.
Optar por una copia de seguridad también tiene más sentido si la inconsistencia está en tu plantilla predeterminada. La decisión consiste en valorar qué es más rápido: restaurar desde una copia de seguridad limpia o editar cada entrada por separado.
Usar la API de Kinsta para trabajar con copias de seguridad
Con la API de Kinsta, también tienes una forma programática de hacer copias de seguridad. Por ejemplo, es posible etiquetar las copias de seguridad manuales para identificarlas más tarde:
curl -i -X POST \
'https://api.kinsta.com/v2/sites/environments/{env_id}/manual-backups' \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
-H 'Content-Type: application/json' \
-d '{
"tag": "pre-batch-publish"
}'
Para restaurar el entorno desde una copia de seguridad, utilizas un endpoint diferente con un formato similar:
curl -i -X POST \
'https://api.kinsta.com/v2/sites/environments/{target_env_id}/backups/restore' \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
-H 'Content-Type: application/json' \
-d '{
"backup_id": 123456789,
"notified_user_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1"
}'
Los endpoints de la API son perfectos para integrarlos en un flujo de trabajo ya existente o para incorporarlos a un proceso nuevo. Los seis tipos diferentes de copias de seguridad de Kinsta te ofrecen mucha flexibilidad. Sin embargo, solo tienes cinco espacios disponibles para las copias de seguridad manuales. Por eso, tu script debería incluir un contador (o eliminar las copias de seguridad antiguas) para asegurarte de que no se produzca ningún error.
Las copias de seguridad automáticas diarias y las opcionales por horas son adecuadas para la mayoría de las tareas. Sin embargo, dependiendo de la tarea y la funcionalidad, puede ser más adecuado hacer una copia de seguridad manual o externa. Por ejemplo, si usas una copia de seguridad manual etiquetada antes de publicar cambios en lote, podrás encontrar el punto de restauración adecuado en cuestión de segundos, en lugar de tener que buscar entre las copias de seguridad diarias u otras copias automáticas.
¿Por qué las correcciones en el contenido no se verán hasta que borres la caché?
Una situación muy habitual es tener que corregir un cambio en el contenido que parece correcto en el editor de entradas, pero que sigue mostrando el contenido antiguo en el front end. Esto suele deberse a que la caché se ha quedado atascada.
En un proceso de creación de contenido con IA general, es muy fácil pasar esto por alto. Como vaciar la caché es lo mismo que apagar y volver a encender el dispositivo, muchos flujos de trabajo no lo incluyen. Además, vaciar la caché es fundamental para que las correcciones en lote se reflejen de inmediato en el front end.
Si nadie revisa el resultado del script, vaciar la caché garantiza que el front end coincida con la versión actual. Además, vaciar la caché tiene una ventaja para el SEO, ya que los rastreadores pueden indexar esa misma versión actual.
Kinsta ofrece varias formas de borrar la caché, tanto desde MyKinsta como a través de la API. Cada método tiene su propio endpoint:
const clearSiteCache = async (environmentId) => {
const resp = await fetch(`https://api.kinsta.com/v2/sites/tools/clear-cache`, {
method: 'POST',
headers,
body: JSON.stringify({ environment_id: environmentId })
});
const data = await resp.json();
return data.operation_id;
};
Dependiendo del endpoint que elijas (como, por ejemplo, trabajar con las opciones de caché del CDN o edge caching), los parámetros de la solicitud body son diferentes.
El momento adecuado para añadir un paso de limpieza de la caché es en la fase de corrección, para que puedas confirmar que un cambio ya está activo en lugar de darlo por hecho. La limpieza de la caché debería realizarse cada vez que ejecutes una parte de tu script que una persona comprobaría manualmente. No es totalmente equivalente a una verificación humana, pero sí te permite trabajar con la versión más actualizada de tu contenido.
Cómo usar los registros de actividad para hacer un seguimiento de los cambios en flujos de trabajo con gran volumen de contenido
La presión de crear contenido y trabajar con un calendario de publicación tan apretado se ve agravada por el número de miembros del equipo que trabajan en ese objetivo. Entender cómo se cuelan los errores en tu contenido es complicado, y atribuir la responsabilidad es aún más difícil.
Los registros de actividad del sitio y de los usuarios de MyKinsta te permiten diferenciar las acciones genéricas de las asignadas. Puedes consultar la pantalla Actividad de los usuarios en el panel de control de MyKinsta, donde encontrarás filtros para ver acciones específicas de usuarios o de la API, junto con la fecha y la hora:
Esto te permite rastrear el origen de cualquier inconsistencia. Por ejemplo, saber que una API de terceros está provocando un error te permite resolverlo rápidamente sin tener que realizar un largo trabajo de investigación. Sin embargo, también puedes obtener información sobre la actividad de los usuarios a través de la API de Kinsta:
const getActivityLogs = async (companyId, category = 'siteActions', limit = 10, offset = 0) => {
const resp = await fetch(
`https://api.kinsta.com/v2/company/${companyId}/activity-logs?limit=${limit}&offset=${offset}&category=${category}`,
{ method: 'GET', headers }
);
const data = await resp.json();
return data.company.activity_logs.items;
};
La API te permite filtrar con mayor detalle que el panel de control de MyKinsta, que solo te permite filtrar por usuario y clave de API. Con la API, puedes filtrar por rol de usuario, advertencias marcadas, el ID de la clave de API y mucho más.
Cómo incorporar controles de gobernanza en tu flujo de trabajo actual de generación de contenidos
Añadir controles a tu flujo de trabajo actual solo debería alargar el tiempo de ejecución en unos cinco minutos más o menos. Sin embargo, los beneficios siguen aportando valor a largo plazo, aunque tienes que revisar todo el flujo de trabajo con regularidad.
- Comprueba si tu equipo utiliza el entorno staging y si el contenido se envía allí.
- Confirma qué miembros del equipo tienen acceso Administrador del Sitio.
- Comprueba que una tarea de publicación reciente etiquete sus copias de seguridad.
- Comprueba que una corrección que haga tu equipo se haya publicado.
MyKinsta te muestra el estado actual de cada comprobación. Para staging, fíjate en el menú desplegable que hay en la parte superior de la pantalla Información. La pantalla Sitios te permite revisar todos los sitios a la vez:
Para comprobar si un usuario es administrador de un sitio, ve a Configuración de la empresa > Usuarios:
Del mismo modo, la pestaña Copias de seguridad te permite ver las copias de seguridad manuales más recientes con etiquetas. Para comprobar las correcciones, ve a una entrada que sepas que ha sufrido un cambio reciente, borra la caché y comprueba la URL en producción en una ventana privada del navegador.
Tras unas cuantas comprobaciones manuales, puedes añadir los pasos a tu script. Sin embargo, debes asegurarte de que todo sigue funcionando correctamente de forma habitual. Ninguna de tus automatizaciones debe ser del tipo «configúralo y olvídate».
Tu flujo de trabajo debería funcionar bien en ambos extremos de tu pipeline de publicación
La IA generativa (GenAI) hace que producir contenido sea más rápido y barato, pero muchas agencias no tienen en cuenta la escalabilidad. La edición de tu contenido (como la verificación de datos, los cambios en el tono de voz y demás) depende de ti. En cuanto a tu proveedor de alojamiento, lo mínimo imprescindible en materia de gestión incluye la capacidad de preparar el contenido en un entorno staging, establecer los permisos adecuados, programar copias de seguridad y mostrar la actividad de los usuarios.
Kinsta te ofrece todo esto a través del panel de control y la API. El conjunto completo de funcionalidades y la infraestructura te proporcionan una forma escalable de gestionar el volumen de publicaciones. El alojamiento para agencias en Kinsta también ofrece la opción de marca blanca para que puedas vender el mismo alojamiento fiable a tus clientes.
