«Hecho» no es una medición: los tres estados de una tarea SEO

Un plan de trabajo SEO se entrega, se reparte en tarjetas, alguien lo hace y alguien confirma que está hecho. En ese punto, todo el mundo da la tarea por cerrada.

No lo está. Falta el paso que enseña algo, y es el que casi nadie da.

Los tres estados

Los dos primeros existen en cualquier empresa. El tercero casi nunca.

Y el tercero es el único que enseña algo. Una tarea ejecutada impecablemente cuya métrica no se mueve es la información más valiosa que un sistema así puede producir: significa que el hallazgo estaba mal ponderado, o que no era la causa de nada.

Por eso «sin cambio» no es un fallo del registro. Es un resultado, y es el resultado que hace que la próxima auditoría sea mejor que la anterior.

La regla de oro: el parte del ejecutor no es la medición

Esta la aprendimos de la peor manera, que es la única que se aprende.

Cerramos las dos primeras tareas del registro fiándonos del documento de asignación, que decía que ambas estaban comprobadas en una fecha concreta. Alguien preguntó lo obvio: «¿fuiste a verlo?».

De las dos, solo una se había verificado de verdad.

Que el responsable de proyecto, el desarrollador o el cliente digan «hecho» es una declaración, no una medición. Los tres son honestos y ninguno miente; lo que pasa es que están informando de que hicieron un trabajo, no de que el efecto se produjera. Son dos preguntas distintas.

Desde entonces, el valor posterior solo se rellena con una comprobación propia y fechada. Si no la hay, la tarea se queda en «ejecutada».

Y al comprobarlo de verdad, sale mejor evidencia

Lo que no esperábamos: verificar por nuestra cuenta no solo confirmaba, sino que producía pruebas mejores que el parte.

La fecha exacta del cambio en el registro es prueba documental de cuándo se ejecutó. El parte no lo es. Y comprobar las cuatro combinaciones de host, en vez de la que a uno le viene a la cabeza, es la diferencia entre saberlo y suponerlo.

El estado que evita meter prisa falsa

Añadimos un cuarto estado, «en cartera», y resultó importante por una razón que no es técnica.

El registro nacía poniendo todas las tareas como «asignadas», y era falso: una tarea derivada de un plan no está asignada hasta que sale en una asignación emitida y llega a quien la ejecuta. Muchas seguían en el cajón, y con razón: un informe profundo abre conversaciones internas antes de que nadie pueda ponerse a trabajar.

Un registro que da por asignado lo que todavía se está decidiendo convierte una decisión prudente en un semáforo en rojo, y presiona a gente que no ha recibido nada.

El reloj solo corre para lo ejecutado. El aviso automático mira tareas ejecutadas hace más de treinta días y nunca medidas. Lo que está en cartera no dispara nada, pase el tiempo que pase. El sistema vigila que no se pierda una medición, no que se trabaje deprisa.

Qué se puede automatizar y qué no

De las 161 métricas de control de nuestra cartera, el 52% es comprobable por máquina: cabeceras y redirecciones, recuentos de un rastreo, cifras de Search Console o de Analytics.

El otro 48% exige criterio: si un texto responde mejor a la intención de búsqueda, si una estructura de contenido es más clara, si un enlace está bien colocado.

La regla que aplicamos: el script mide lo que puede y deja lo demás marcado como pendiente. Nunca lo inventa. Un registro que rellena huecos con estimaciones deja de ser un registro.

Adónde lleva esto

Con veinte tareas medidas se puede responder a una pregunta que hoy no tiene respuesta en ninguna agencia que conozcamos: ¿un criterio al que damos peso alto mueve realmente más la aguja que uno al que damos peso bajo?

Si la respuesta es que no, los pesos están mal, y con ellos todas las priorizaciones que se han hecho con ellos.

La honestidad del dato

Estado real de la cartera cuando escribimos esto: 159 tareas en cartera o ejecutadas, 2 medidas. Dos.

Así que este artículo no describe un sistema que funcione: describe un sistema que acabamos de montar y un agujero que llevábamos años teniendo sin verlo. Los pesos que usamos para priorizar siguen siendo criterio experto sin una sola validación, y lo son también en el informe que te haya entregado cualquier otro.

No lo publicamos como método probado. Lo publicamos porque la pregunta —«¿y después de hacerlo, se movió algo?»— es la que deberías hacerle a cualquiera que te entregue un plan de trabajo, y la mayoría no tiene con qué contestarla. Nosotros tampoco la teníamos.

Preguntas frecuentes

¿Cómo hago seguimiento de las tareas SEO?

Con tres estados en lugar de dos: asignada, ejecutada y medida. La mayoría de los sistemas se detienen en «ejecutada», que solo dice que alguien hizo un trabajo. El tercer estado exige volver a la métrica que justificaba la tarea y comprobar si se movió, semanas después.

¿Vale con que el cliente o el desarrollador confirmen que la tarea está hecha?

Para saber que se hizo, sí. Para saber si funcionó, no. Son dos preguntas distintas, y la segunda solo se contesta comprobando la métrica por tu cuenta y con fecha. Al comprobarlas nosotros, una de las dos primeras tareas que dábamos por verificadas no lo estaba.

¿Qué hago si una tarea se ejecutó bien y la métrica no se mueve?

Registrarlo como resultado, no como fallo. Significa que el diagnóstico sobrevaloraba ese problema o que la causa era otra, y es exactamente la información que hace que la siguiente auditoría se equivoque menos. Borrarlo o dejarlo sin cerrar es tirar el único aprendizaje del ciclo.