Errores de QA en el orden de los enlaces: siete informes de error con soluciones

Por qué las soluciones son pequeñas

Observa que ninguna de ellas necesita una segunda suscripción. El QA de enlaces comprados es principalmente contabilidad, y la contabilidad que importa ocurre en la fecha de entrega.

Lo que cuesta dinero es el descubrimiento tardío. Siempre. Un lote de 40 enlaces pagados por anticipado, encontrado roto tres meses después, te deja discutiendo sobre una ventana de garantía que puede haber cerrado. Ejecuta las verificaciones el día 0, el día 30 y el día 60 y la ventana funciona a tu favor.

Para un calendario concreto con números inventados pero plausibles, consulta el ejemplo trabajado de 40 enlaces. Para los términos utilizados en esta lista, el glosario está a un clic de distancia.

Dónde se une nuestra API al bucle

Después del bucle de shell, llama a refdomains una vez para el dominio del cliente y diferencia la lista de hosts contra la hoja. Eso son 2 créditos, $0.0002, y una solicitud cubre hasta 1.000 filas.

Los hosts presentes en la hoja y ausentes en la lista reciben la etiqueta pending hasta la próxima actualización mensual. Los hosts presentes en ambos se confirman cruzadamente. Una lista corta, claramente etiquetada, es el entregable que realmente lee tu gerente. Nadie abre el JSON crudo, y nadie debería tener que hacerlo. Guarda el volcado en almacenamiento por si un proveedor disputa una fila seis semanas después.

Cuánto tiempo debería tomar una pasada de QA de pedidos de enlaces

El QA de pedidos de enlaces toma menos tiempo de lo que la mayoría asume. El tiempo va a un solo lugar. Escala con el número de URLs de origen y con cuántas de ellas lees manualmente, mientras que el tamaño del propio sitio web del cliente importa mucho menos.

Cuenta las URLs de origen, no las páginas del cliente

Imagina un sitio web de una pequeña empresa de aproximadamente 200 páginas que recibió 40 enlaces desde fuera. El trabajo son las 40 páginas de origen más las URLs de destino. Las otras 200 páginas del lado del cliente no forman parte de una verificación de enlaces. Digamos que esos 40 enlaces provienen de 12 hosts distintos. El bucle de obtención se ejecuta entonces 40 veces, una por URL, y el diff de refdomains se ejecuta una vez por cliente. Contándolo de esta manera, la estimación se convierte en aritmética.

Si alguien cotiza varios días de trabajo para una verificación de enlaces, pregunta qué tareas cubre la cotización. Una auditoría completa del sitio y una verificación de enlaces son trabajos diferentes, y solo uno de ellos necesita un crawler de todo el dominio.

Automatiza la obtención, luego lee las excepciones

El bucle de shell en esta guía obtiene cada página de origen y busca el enlace. Una persona lee solo las filas que el script no pudo confirmar, como un ancla faltante o un valor rel inesperado.

Eso mueve el esfuerzo de leer cada página a decidir sobre un puñado de filas.

Lo que añade una revisión manual todavía

Una revisión manual captura lo que un script no puede. Ejemplos son un enlace inyectado por JavaScript, un muro de pago o un diseño que oculta el ancla. Presupuéstalo en las filas que más importan, no en toda la hoja.

Escribe el presupuesto antes de que comience el trabajo, para que la revisión tenga un punto final. Un hábito útil es muestrear tres o cuatro filas manualmente después de cada lote, no todas las filas, y registrar qué filas se leyeron.

Cuáles de los siete errores aparecen primero

No todos los errores aparecen el día 0. Algunos esperan a que un redireccionamiento, una actualización de plugin o una regla de staging cambie. Conoce cuáles son tardíos. Eso determina la segunda y tercera verificación.

Los redireccionamientos y las reglas de staging aparecen temprano

Si la URL de destino redirige dos veces, o una regla de staging bloquea a los bots, el problema generalmente aparece en la primera semana. Por eso el error 5 pertenece al script del día 0 y no a uno posterior.

Ejecuta curl -I en tu propia URL el mismo día que se reporta el enlace como en vivo.

La deriva de rel llega después de las actualizaciones de plugins

Una actualización de plugin puede reescribir un atributo rel mucho tiempo después de la entrega. Un enlace que estaba seguido el día 0 puede leerse como sponsored el día 60, sin que nadie toque el artículo.

Así que la verificación de rel pertenece a cada re-verificación, no solo a la primera. Analiza el atributo desde el HTML obtenido cada vez y compáralo con el pedido.

Las URLs incorrectas y las calificaciones incorrectas se encuentran en la etapa de la hoja

El error 2, la página de inicio en lugar del artículo pagado, y el error 4, comparar calificaciones entre herramientas, generalmente se detectan antes de que se ejecute cualquier obtención. Ambos provienen de la hoja misma, por lo que son baratos de corregir en ese punto.

Corrígelos antes de la primera ejecución del script. Cada paso posterior hereda lo que dice la hoja, y una obtención de la URL incorrecta devuelve una respuesta limpia sobre la página incorrecta.

Una hoja que nombra una URL de origen exacta para cada fila, y una métrica para la calificación, elimina dos de las falsas alarmas más comunes en todo el proceso.

Los reemplazos necesitan las mismas siete verificaciones

Un enlace de reemplazo es un enlace nuevo. Merece las mismas siete verificaciones que el primer lote, y comienza su propio reloj. Trata el intercambio como una nueva línea de pedido. No un parche.

Por qué la fila antigua no se transfiere

La evidencia antigua describe una página que ya no lleva tu enlace. No demuestra nada sobre el nuevo. Guárdala para el archivo de disputa y comienza un conjunto fresco de evidencia para el reemplazo.

Registra ambas URLs de origen en la misma fila, para que el rastro se lea claramente más tarde.

Pruebas dentro de la ventana de reemplazo

Si el contrato nombra una ventana para intercambiar un enlace muerto, prueba el intercambio dentro de esa ventana. Un reemplazo probado en su último día no deja margen para corregir un segundo problema.

Usa la ventana como fecha límite para verificar, y programa la verificación antes de que cierre.

Calificar nuevamente el nuevo dominio

Un reemplazo a menudo proviene de un dominio diferente, y ese dominio puede tener una calificación menor que la que reemplazó. Ejecuta la verificación de piso nuevamente en el nuevo host antes de aceptar el intercambio.

Una llamada bulk_dr cubre toda la lista de reemplazos, así que hay poca razón para omitirla.

Lo que debería mostrar la hoja del gerente

Una hoja de QA de pedidos de enlaces es el entregable. Cada fila lleva un estado y algunas fechas, y la evidencia está detrás de la fila en almacenamiento. La evidencia permanece oculta. El gerente lee el resumen.

Un estado por fila

Usa pass, pending o fail, y nada entre ellos. Una fila que está en vivo pero aún no indexada es pending, no un medio-pass. Los medios-envíos devuelven la revisión mensual a una discusión sobre la redacción.

Si necesitas un cuarto estado, nómbralo primero en el contrato.

Fechas junto a cada estado

Cada fila necesita el día en que obtuviste la página, el día de la última actualización que conocías y el día de la próxima verificación. Esas tres fechas responden a la mayoría de lo que pregunta un gerente.

Una fila sin fechas invita a la pregunta de si la verificación ocurrió en absoluto.

Mantener el volcado crudo para una disputa

Almacena el HTML guardado, los volcados de encabezados y las respuestas de la API en una carpeta con el nombre del lote. Mantén la carpeta durante tanto tiempo como una disputa pueda abrirse, ya que un proveedor puede cuestionar una fila mucho después de que el resumen se cerrara.

Haz la carpeta de solo lectura una vez que el lote se cierre, para que la evidencia coincida con lo que reportaste.