Las consultas de DR gratuitas no requieren clave. Inicia sesión para obtener $100 en crédito.
Hipotético
Cada cifra aquí es inventada para mostrar el método. No se describe ningún cliente, proveedor o resultado real.
La agencia, el proveedor, los dominios y todas las cifras siguientes son ficticias. Existen para mostrar la aritmética y la estructura. Tu lote será diferente.
Imagina una agencia que compró 40 ubicaciones para un sitio de cliente, a un precio fijo por enlace, con un piso de DR garantizado de 30 y una ventana de reemplazo de 60 días. La hoja del proveedor enumera 40 URLs de origen y 40 textos ancla.
Nada de esto es inusual. La pregunta es cómo convertir esa hoja en una tabla de aprobado/reprobado. Utilizamos tres puntos de control: día de entrega, día 30 y día 60.
| Punto de control | Página en vivo obtenida | Host en la lista de refdomains | Rel según lo pedido | Notas |
|---|---|---|---|---|
| Día 0 | 38 de 40 | 0 de 40 (aún no indexado) | 36 de 38 | 2 URLs 404, 2 rel=sponsored añadidos |
| Día 30 | 37 de 40 | 29 de 40 | 35 de 37 | 1 más eliminado, índice actualizado el día 22 |
| Día 60 | 36 de 40 | 34 de 40 | 35 de 36 | Reemplazos pendientes para 4 |
El día 0 muestra cero hosts en el índice. Eso es normal. Un cero en la entrega no es un defecto; un cero después de dos actualizaciones sí lo es.
Para el día 60, cuatro enlaces han desaparecido. Dos más han cambiado, porque llevan una etiqueta sponsored que el pedido no mencionaba. Fíjate en la diferencia. Si la etiqueta cuenta como un defecto depende del contrato, por lo que la hoja debe indicar qué se pidió en palabras claras. El glosario enumera los valores rel que puedes citar.
El piso de valoración se verifica una vez con bulk_dr. Una sola llamada. En el ejemplo, 40 dominios en una llamada cuestan 1 crédito, y 3 dominios obtienen una puntuación inferior a 30 según nuestra fórmula. Esos tres van al ticket primero porque son objetivos y baratos de demostrar.
Una valoración por debajo del piso no es una cuestión de gusto. Una regla que se resuelve con un número gana confianza para las filas subjetivas que vienen después.
Para el día 60, el lote inventado muestra 4 páginas faltantes y 2 etiquetas sponsored. Los dos grupos requieren un manejo diferente, y la ordenación es el paso que convierte una lista de fallos en un ticket.
De las 4 páginas faltantes, supongamos que 3 fueron eliminadas por el editor y 1 se movió a una nueva URL. El movimiento es fácil de pasar por alto. Una redirección desde la dirección antigua se mostraría como un 301 en el volcado de cabeceras guardado, por eso las cabeceras se almacenan junto con el HTML.
Las 2 etiquetas sponsored son una clase diferente de problema. Los enlaces funcionan. Es probable que el proveedor diga que la etiqueta es la opción honesta. Decide de antemano si una etiqueta cuenta, porque una disputa resuelta por gusto desperdicia una semana.
| Paso | Llamadas | Créditos | Dólares |
|---|---|---|---|
| bulk_dr en 40 dominios | 1 | 1 | $0.0001 |
| refdomains en los días 0, 30 y 60 | 3 | 6 | $0.0006 |
| anclas en el día 60 | 1 | 2 | $0.0002 |
| Total | 5 | 9 | $0.0009 |
La columna de página en vivo proviene de curl en la máquina del probador, no de nuestra API. No ofrecemos esa verificación, y fingir que sí lo haríamos ocultaría la parte más laboriosa del trabajo.
Los créditos son casi secundarios. El trabajo es leer 40 páginas. Si quieres reducir eso, automatiza el grep de la lista de errores y mantén la vista atenta a las 4 o 5 filas que fallen.
Para una vista mes a mes de todo un portafolio de clientes, pasa a la tabla de costes. Si las posiciones de búsqueda cambiaron después del lote, el manual de caída de tráfico es la siguiente parada.
Las mismas cuatro acciones se ejecutaron en el día 0, día 30 y día 60, por lo que cada punto de control se pudo comparar con el anterior.
Las 40 páginas se obtuvieron una vez por punto de control, guardando y fechando el HTML y las cabeceras. Una obtención fallida es una fila en la tabla, nunca una celda en blanco.
Una llamada refdomains por punto de control devolvió la lista de hosts para el cliente. Se esperaba una lista escasa el día 0, por lo que la fila se marcó y se dejó para el siguiente punto de control.
Cada host y cada valor rel se compararon con el punto de control anterior así como con el pedido. Un cambio entonces se muestra como un cambio, con una fecha adjunta.
Las reglas al final de esta página se aplicaron fila por fila. La evidencia se mantuvo junto a cada fila, por lo que un veredicto disputado se podía abrir de nuevo.
Cada punto de control hacía una pregunta principal. Mezclarlas es la razón habitual por la que un resultado del día 0 se discute el día 60.
El día 0 la pregunta es estrecha. ¿Está la página en vivo, y existe el texto ancla en el HTML guardado? No se espera que el índice lo sepa aún, por lo que un conteo de hosts cero no responde nada. Anota eso y deja la pregunta del índice para más tarde.
Una prueba útil del día 0 es si el HTML obtenido contiene la cadena exacta del ancla del pedido. Si la contiene, la fila es aprobada-pendiente. Si no la contiene, la fila falla antes de que siquiera surja la pregunta del índice.
En el lote inventado, el índice se actualizó el día 22, por lo que el día 30 es la primera mirada honesta a la lista de hosts. Los hosts que aparecen ahora confirman la colocación. Los hosts que aún no aparecen son candidatos para la columna pendiente, y el siguiente punto de control los decide.
El último punto de control busca desplazamientos: un valor rel que cambió, un ancla que se movió, o una página que ahora redirige. Compara cada fila con el día 30, no solo con el pedido, para que un cambio se muestre como un cambio.
El día 60 también es el punto natural para verificar si los reemplazos aún están dentro de su ventana, ya que es cuando una fecha límite no observada tiende a pasar.
Un ejemplo práctico es ordenado. Los lotes reales son más desordenados de formas que una tabla inventada no puede mostrar, y vale la pena nombrar esas antes de copiar la disposición.
Un host puede cambiar de dueño entre puntos de control, con nuevo contenido y una nueva plantilla. El enlace puede seguir en vivo, pero ya no estar en el tipo de sitio que describió el pedido. Compara el título de la página y el bloque de autor, no solo la URL.
Un cambio de dueño no falla automáticamente la fila, pero sí cambia lo que la fila demuestra.
Añade la verificación de propiedad a las reglas de veredicto si tu lote es lo suficientemente largo como para que importe.
Algunas páginas muestran un enlace solo en un módulo rotativo, una barra lateral que cambia por visita, o una lista cortada a los elementos más nuevos. La obtención puede perder el ancla en una ejecución y captarlo en la siguiente. Cuando una fila falla una vez, obténla dos veces el mismo día y registra ambos resultados. Mantén una nota de la rotación en la fila, ya que un resultado pendiente de un módulo rotativo no es lo mismo que un enlace faltante.
Un lote que mezcla idiomas hace más difícil la verificación del ancla, porque el ancla puede estar traducido o flexionado en la página donante. Compáralo con la redacción acordada en el pedido, y marca el idioma junto a la fila para que un revisor sepa por qué difiere.
Este ejemplo de auditoría de backlinks es una plantilla, no un resultado. Su estructura se transfiere a cualquier pedido. Sus números no, y nadie debería leerlos como un punto de referencia.
La tabla de puntos de control, la lista de créditos y las reglas de veredicto se transfieren a un nuevo lote. Los conteos no. Reemplaza cada cifra inventada con la tuya antes de que alguien lea el resultado. Mantén las fechas de los puntos de control en la forma día 0, día 30 y día 60, para que un revisor pueda hacer coincidir tu hoja con esta página de un vistazo.
Escribe las reglas de veredicto antes de la primera obtención, y no las edites cuando una fila decepcione. Una regla cambiada después del resultado es una disputa esperando ocurrir.
Si el contrato del proveedor hace referencia a las mismas reglas, ambas partes leen el mismo texto. Una fila pendiente entonces significa lo que el contrato dice que significa, y la discusión pasa de la interpretación a la evidencia.
Un pedido de 40 filas costó 9 créditos en el ejemplo. Un pedido más grande cambia el número de llamadas, no el método. Cuenta las llamadas por punto de control, multiplica, y verifica que el total aún se ajuste al presupuesto que estableciste. La obtención sigue siendo por enlace, por lo que el tiempo de lectura crece con las filas mientras la línea de créditos apenas se mueve.
