Auditoría de enlaces tras la publicación con GitHub Actions o cron estándar
La publicación está en línea y el pipeline no ha terminado. Este manual añade una auditoría programada que registra datos de enlaces por sitio y notifica a una persona solo cuando algo parece incorrecto.
Equipo de investigación de SEOBlogBot ·
Por qué auditar después de publicar
Una puerta de control ve un borrador. Una auditoría ve lo que realmente hace el sitio en vivo. Los complementos reescriben enlaces, los editores pegan redirecciones de afiliados sobre URLs limpias y una migración de CDN puede cambiar un host por otro. Nada de esto existe en la etapa de borrador, por eso una ejecución tras la publicación es el primer lugar donde puede aparecer.
Una auditoría útil es aburrida por diseño. Se ejecuta en un horario, escribe una línea y se mantiene en silencio a menos que se dispare una excepción. El silencio es el objetivo. Un mes de registros silenciosos significa que el trabajo funciona, no que está inactivo.
No existe una API oficial de verificador de backlinks de Google para uso general, por eso los equipos llaman a un índice de enlaces de terceros. Es nuestro propio rastreador. Search Console muestra la vista de Google de tus propios enlaces, y la auditoría los complementa en lugar de reemplazarlos.
Dónde se ejecuta el trabajo
Escribe el activador. Tres configuraciones cubren la mayoría de los equipos, y cada una ejecuta las mismas llamadas. El registro es más importante que el activador, porque la fecha, la URL y los créditos utilizados deben llegar allí cada vez.
GitHub Actions para un repositorio
Si el sitio se construye desde un repositorio, un flujo de trabajo programado añade la menor fricción. El trabajo vive junto al código, y la clave se encuentra en la tienda de secretos del repositorio. El archivo de flujo de trabajo más abajo es lo mínimo que necesitas. Mantenlo en el repositorio, revisado como cualquier otro código, y fija las versiones de las acciones en las que confías.
Un servidor simple con cron
Los equipos que ya mantienen una máquina para su compilación pueden programar los mismos comandos allí. Una herramienta como n8n puede ejecutarlos a través de un paso de Ejecutar Comando, o una línea de crontab puede ejecutarlos directamente. De cualquier manera, el trabajo debe ejecutarse como un usuario que pueda leer la clave y nada más.
Un webhook desde tu CMS
Algunas configuraciones de CMS activan un webhook cuando una publicación está en línea, y ese evento puede iniciar la auditoría. La verificación se ejecuta en el momento en que la publicación es pública. Mantén también una ejecución programada, porque un único webhook perdido deja una publicación sin verificar.
El manual de operaciones, en orden
01
Activar al publicar y de nuevo 30 días después
Una ejecución justo después de que la publicación esté en línea verifica los hosts de salida. Una segunda ejecución un mes después lee refdomains para tu sitio, porque el índice se actualiza aproximadamente una vez al mes y una lectura anterior no mostraría nada nuevo.
02
Llama primero al resumen gratuito
action=overview devuelve los números principales del sitio sin costo. Guárdalos como la fila de línea base para esta ejecución, junto con la fecha.
03
Obtén las listas pagadas solo si hay cambios
Si el resumen difiere del mes anterior, llama a refdomains (2 créditos) y anchors (2 créditos) y compara con las listas almacenadas.
04
Escribe una línea en un registro
Fecha, URL de la publicación, llamadas realizadas, saldo de _credits. Un CSV plano comprometido en un repositorio privado es suficiente.
05
Alerta solo en excepciones
HTTP 401, HTTP 402, un resultado vacío para un sitio que tenía filas el mes anterior, o una caída de clasificación de 10 puntos o más.
Qué sitios auditar
Comienza con el dominio que aloja la publicación. Luego ejecuta la misma auditoría contra dos o tres pares que quieras comparar. Usa compare para eso. Toma hasta 20 dominios por 1 crédito, por lo que la verificación de pares cuesta casi nada.
Salta la larga cola. Cada sitio adicional añade ruido a un registro que una persona tiene que leer. Una comparación de veinte dominios no relacionados te dice muy poco sobre el tuyo.
Mantener la clave fuera de los registros
Un trabajo programado lee su clave en cada ejecución, por lo que nunca necesita un paso de inicio de sesión. Lo único que proteger es la clave misma. Tiene tres fugas obvias: un commit, un entorno impreso y una URL que un proxy registra. Cierra cada una.
Usa la tienda de secretos, no un archivo en el repositorio
Pega la clave en la tienda de secretos de tu proveedor de CI, o en un archivo de entorno que solo el usuario del trabajo pueda leer. Nunca lo comprometas. Un paso que ecotiza su entorno lo imprimirá, así que no escribas uno.
Envía la clave en un encabezado
El encabezado Bearer mantiene la clave fuera de la mayoría de los registros de acceso, porque las URLs se registran y los encabezados generalmente no. La forma de cadena de consulta también funciona, pero deja una copia en cada proxy que vea la solicitud.
Limita quién puede leer la tienda
Concede acceso de lectura a las personas que mantienen el trabajo y a nadie más. Revisa esa lista cuando el trabajo cambie de manos.
Una clave que muchas personas pueden leer es una clave que terminará pegada en una ventana de chat algún día.
Valida la respuesta antes de escribirla
Una respuesta que llega no es aún una respuesta que puedas usar. Usa un orden cada vez. Escribe solo lo que pase, y registra el resto. Una respuesta rechazada es evidencia, y la siguiente persona que depure el trabajo querrá verla.
Verifica el estado y ok primero
Lee el código de estado HTTP, luego el campo ok en el cuerpo. Un 200 con ok establecido en falso sigue siendo una llamada fallida, y el registro debe decirlo.
Analiza el JSON antes de cualquier escritura
Confirma que el cuerpo es JSON válido antes de descomprimir, analizar o adjuntar nada. Una descarga truncada puede ocurrir en un ejecutor inestable. Un archivo roto escrito en el registro parece bien hasta que alguien lo abre.
Trata una lista vacía como una pregunta
Un resultado vacío para un sitio que tenía filas el mes anterior es una pregunta, no un hecho. Verifica la ortografía del dominio, incluyendo un www. inicial, antes de que alguien reciba una alerta.
Un archivo de flujo de trabajo para empezar
Almacena la clave como un secreto de repositorio llamado SBB_KEY. La expresión cron se ejecuta el primero de cada mes a las 06:00 UTC.
Vuelve a crear el secreto, ejecuta workflow_dispatch
HTTP 402
Se acabaron los créditos
Recarga desde la página de la cuenta, vuelve a ejecutar
Filas vacías para un sitio conocido
Actualización del índice en progreso o error tipográfico en el dominio
Reintenta en un día; verifica el www.
La clasificación se movió unos puntos
Actualización mensual
No hagas nada; mira la tendencia
La clasificación cayó 10+
Pérdida de enlaces o un cambio grande de actualización
Obtén refdomains y compara
Cron en un servidor simple
Los mismos comandos se ejecutan desde una línea de crontab. Mantén la clave en un archivo de entorno que solo el usuario del trabajo pueda leer, y registra en un archivo que rotarás.
Costos y dónde leerlos
Una auditoría mensual para un sitio cuesta 4 créditos cuando obtienes ambas listas, lo que son $0.0004. La llamada de resumen es gratuita. Un mes sin cambios por lo tanto no cuesta nada más allá de eso.
Si tu equipo publica diez publicaciones al día en varios sitios, la auditoría sigue siendo un trabajo mensual por sitio, no un trabajo por publicación. Eso mantiene el conteo pequeño y el registro legible.
Cuando añadas un segundo sitio, copia el trabajo en lugar de ampliarlo. Un flujo de trabajo por dominio mantiene el registro por sitio y hace que un fallo sea fácil de rastrear hasta su propietario.
El costo mayor suele ser los minutos de tu proveedor de CI, no nuestros créditos. La tabla de costos pone ambas líneas lado a lado, para que puedas decidir cuál ajustar primero.
Pide a la primera ejecución que imprima _credits. Confía en la respuesta por encima de cualquier tabla. La guía de puerta de control cubre la verificación del lado del borrador que viene antes de esta.
El planificado de GitHub se ejecuta en UTC, por lo que un inicio a las 06:00 cae en una hora local diferente para cada equipo. Escribe la zona horaria en el manual de operaciones para que nadie se sorprenda con el registro.
Preguntas sobre la ejecución de la auditoría
La mayoría de estas preguntas provienen de equipos que acaban de programar el trabajo por primera vez.
¿Es esta una API de verificador de backlinks de Google?
Es una auditoría construida sobre nuestra propia API, no un producto de Google. Google no publica una API general de backlinks, por lo que los números provienen de nuestro propio rastreador y nuestro propio índice.
¿Puede la auditoría ejecutarse con cada compilación?
Puede, pero una extracción mensual de refdomains no necesita ejecutarse en cada compilación. Ejecuta el resumen gratuito en cada publicación, y las extracciones pagadas una vez al mes.
¿Sigo necesitando la auditoría si tengo una puerta de control?
Sí, si publicas a través de complementos o una CDN. La puerta de control ve tu borrador, y la auditoría ve la página en vivo. Cada una captura fallos que la otra no puede ver.
¿Qué pasa si el trabajo falla a mitad de camino?
Escribe el resultado de cada paso en su propio archivo, para que una extracción fallida deje el resumen intacto. Vuelve a ejecutar desde el paso fallido en lugar de desde el principio, lo que evita pagar por la misma extracción dos veces.
¿Cuántos créditos debo presupuestar por cada sitio?
Presupuesta 4 créditos por sitio por mes para las dos extracciones pagadas, más lo que gaste tu puerta de control en borradores. El resumen gratuito no añade nada a esa cifra, y el registro te dice el total real.
¿Por qué dos ejecuciones a pocos días de diferencia discrepan?
El índice se actualiza aproximadamente una vez al mes, por lo que los cambios día a día suelen ser ruido. Compara la instantánea de este mes con la del mes anterior antes de abrir un incidente.
Firma del manual de operaciones
El secreto existe y el flujo de trabajo se ha ejecutado una vez manualmente.
El archivo de registro registra fecha, URL, llamadas y _credits.
Alguien es dueño del canal de alertas.
El trabajo trata los datos mensuales como mensuales.
Un fallo de la auditoría misma llama a una persona.
