Gestión de proyectos SEO: entregar, no presentar

La gestión de proyectos SEO es la disciplina de convertir recomendaciones de búsqueda en cambios publicados: dimensionar el trabajo, puntuarlo según su impacto en el negocio, secuenciarlo alrededor de la capacidad de desarrollo y verificarlo en producción. A diferencia de la gestión de proyectos genérica, su restricción real no es el tiempo ni el presupuesto, sino la aceptación del ticket: SEO casi nunca controla el código que necesita cambiar.

Según Search Engine Journal (2026), un equipo SEO corporativo abrió más de 1.400 tickets en dieciocho meses y no se implementó ninguno.

Google Search Central (2026) indica que un sitio puede tardar de cuatro meses a un año en beneficiarse de las mejoras SEO: un reloj que arranca cuando el cambio se publica, no cuando se recomienda.

El estudio de Ahrefs sobre unos mil millones de páginas (2023) encontró que el 96,55% no recibe ningún tráfico orgánico desde Google.

Todas las guías que ocupan la primera página de esta búsqueda recomiendan una herramienta. Asana, Monday, ClickUp, Trello, alguna plataforma SEO con vista Gantt. Ninguna aborda lo que de verdad mata los programas SEO: recomendaciones que desarrollo nunca implementa.

He auditado suficientes sitios como para ver el mismo patrón desde los dos lados. La auditoría es correcta. El roadmap tiene sentido. Dieciocho meses después las etiquetas canonical siguen mal. Eso no es un fallo de estrategia ni de herramienta. Es un fallo de entrega, y tiene solución.

Qué es realmente la gestión de proyectos SEO

Si quitas el lenguaje comercial, la gestión de proyectos SEO es una sola cosa: la capa que convierte una recomendación en un cambio publicado y verificado.

La mayoría de disciplinas no necesitan nombrar esta capa porque quien decide es quien ejecuta. Un responsable de SEM que quiere un grupo de anuncios nuevo lo crea. Un SEO que quiere un arreglo de renderizado abre una petición y espera. Ese hueco —entre decidir y publicar— es el trabajo entero.

Por eso «gestión de proyectos SEO» y «gestión de proyectos aplicada al SEO» son cosas distintas. La gestión genérica asume que controlas el recurso. La gestión de proyectos SEO asume que no, y se construye alrededor de ganarse un hueco en el sprint de otro equipo.

Si tu empresa tiene un roadmap SEO que nadie fuera de marketing ha leído, no tienes un proyecto SEO. Tienes un documento.

Por qué los tickets SEO mueren en el backlog

La historia de los 1.400 tickets es extrema, pero el mecanismo es corriente. El tiempo de desarrollo se redirige a lanzamientos de producto, iniciativas de dirección e incidencias. Las peticiones SEO, abiertas sin estimación de esfuerzo ni caso de negocio, se hunden al fondo de la cola y se quedan ahí.

Habla con programadores y la queja es siempre la misma: los tickets SEO son vagos, están mal justificados y son difíciles de dimensionar. «Arreglar el contenido duplicado» no es un ticket. Es un tema. Nadie puede estimarlo, así que nadie lo coge, así que envejece hasta que está lo bastante rancio como para cerrarlo.

Los bloqueos se repiten en casi todos los equipos internos con los que he trabajado:

• No hay tiempo de desarrollo asignado a SEO, solo peticiones puntuales
• Limitaciones del CMS que nadie ha documentado, así que la mitad de los tickets son imposibles tal como están escritos
• Propiedad difusa: el arreglo toca plantillas, infraestructura y contenido, y ningún equipo es dueño del conjunto
• Recomendaciones escritas para una audiencia de marketing y entregadas a una técnica
• Sin criterios de aceptación, así que «terminado» es una cuestión de opinión

Fíjate en lo que no aparece en esa lista: una herramienta de gestión de proyectos. Añadir una no cambia nada, porque el fallo ocurre en el momento en que un hallazgo se escribe en el formato equivocado.

Puntúa por proximidad a ingresos, no por esfuerzo estimado a ojo

Casi toda la priorización SEO es una matriz de dos ejes —impacto contra esfuerzo— con los dos ejes adivinados. Produce gráficos que parecen sólidos y se desmontan en cuanto un programador pregunta qué significa «esfuerzo medio» en días.

Sustitúyela por dos números defendibles.

Proximidad a ingresos: cuántos pasos separan la página corregida del dinero. Un canonical roto en una categoría que ya convierte está a un paso. Una mejora de schema en un post de blog de la parte alta del embudo está a cuatro o cinco. Puntúa de 1 a 5, donde 1 es lo más cercano.

Días-desarrollador: exactamente eso. Tu mejor estimación, hecha con un programador delante, del tiempo de construir, probar y desplegar el cambio. No story points, no tallas de camiseta. Días, porque los días se convierten en coste y el coste es el idioma de la reunión donde esto se decide.

Ordena por días-desarrollador dividido entre proximidad a ingresos, de menor a mayor. Primero los arreglos baratos cerca del dinero. Los caros y lejanos esperan y —esta es la parte que cuesta aceptar— algunos no deberían programarse nunca. Una auditoría de 400 puntos no es un plan. Es materia prima para uno.

Auditando sitios para clientes en una docena de mercados, el cambio de mayor apalancamiento no es técnico. Es poner un número real al lado de cada recomendación antes de la reunión donde se fijan las prioridades. Las recomendaciones no mejoran. Su tasa de aceptación se duplica aproximadamente.

El sistema de seis puertas

Este es el proceso que aplico con equipos internos. Cada puerta existe porque el trabajo muere ahí de forma sistemática.

1. Convierte la auditoría en un inventario, no en un documento. Cada hallazgo pasa a ser una fila con un responsable y una plantilla de página afectada. Si un hallazgo no se puede reducir a un cambio discreto, divídelo hasta que se pueda. Una auditoría SEO que llega como un PDF de 60 páginas ya ha fallado esta puerta.

2. Puntúa cada fila por proximidad a ingresos y días-desarrollador. Haz la columna de días con un programador real, de una sentada, antes de presentar nada. Las estimaciones que hiciste tú solo serán cuestionadas y perderás.

3. Escribe el ticket en el formato de desarrollo. Paso de reproducción, comportamiento esperado, comportamiento actual, criterio de aceptación, plantillas afectadas. Enlaza a la documentación de Google Search Central de la norma que invocas, para que la justificación no sea «lo dice el SEO».

4. Compra un porcentaje fijo del sprint, no un favor puntual. Negocia una asignación estable —un 10% de la capacidad de desarrollo es un punto de aterrizaje habitual— en lugar de vender cada ticket por separado. Una asignación estable sobrevive a una repriorización; un favor, no.

5. Define «terminado» como verificado en producción. No mergeado, no desplegado. Verificado: has cargado la URL en vivo, has revisado el HTML renderizado, has confirmado que la cabecera o la etiqueta es correcta. Alrededor de un tercio de los tickets SEO «completados» que reviso nunca se implementaron bien, y nadie lo notó porque el ticket se cerró al hacer merge.

6. Vuelve a verificar a los 30 días. Los despliegues pisan cosas. Una refactorización de plantilla se lleva por delante el bloque hreflang; un cambio de caché revierte una cabecera. Pon una revisión recurrente sobre tus arreglos de mayor valor o pagarás dos veces por el mismo trabajo.

La puerta 5 es donde está la mayor parte del valor recuperable. La puerta 4 es donde el programa se gana o se pierde.

Cómo escribir un ticket que desarrollo acepte

La diferencia entre un ticket ignorado y uno programado suelen ser 200 palabras de concreción.

Un mal ticket: «Las páginas de producto tienen problemas de contenido duplicado, arreglad los canonicals.»

Un buen ticket nombra la plantilla, da un par de URLs que reproducen el fallo, indica la salida actual y la esperada, e incluye una prueba:

Plantilla: /producto/[slug] Reproducción: /producto/widget-azul?color=azul y /producto/widget-azul devuelven HTML idéntico con canonical autorreferenciado. Esperado: las variantes con parámetros emiten <link rel="canonical" href="https://ejemplo.com/producto/widget-azul">. Criterio de aceptación: curl sobre cualquier URL de producto con parámetros; el canonical debe ser igual a la URL limpia. Estimación: 1,5 días-desarrollador (confirmado con Marta, 14 ago). Caso de negocio: 3.100 URLs duplicadas indexadas en el catálogo; las páginas de categoría están a un paso del checkout.

Ese ticket se coge. No porque el razonamiento SEO haya mejorado —es idéntico— sino porque ahora es dimensionable, comprobable y justificado. Esta es la habilidad central del SEO técnico dentro de una empresa con programadores, y casi nunca se enseña.

Las recomendaciones vagas son además la forma silenciosa en que despiden a un consultor. Si no se publica nada, el retainer parece no haber producido nada, por bueno que fuera el análisis.

Mide la entrega, no solo el posicionamiento

Todos los dashboards SEO miden posiciones, sesiones y conversiones. Casi ninguno mide si el trabajo se está haciendo. Añade tres métricas de entrega y diagnostica el programa de un vistazo.

Tasa de implementación. Tickets verificados en producción entre tickets abiertos, por trimestre. Por debajo del 40% tu problema no es la estrategia SEO. Entre el 70% y el 80% es un programa interno sano.

Mediana de tiempo hasta publicar. Días desde que se abre el ticket hasta que está verificado en vivo. Este número determina cuándo empieza siquiera la ventana de cuatro meses a un año de Google. Un equipo con una mediana de 90 días ha añadido un trimestre a todas sus previsiones.

Tasa de regresión. Porcentaje de arreglos verificados que se rompen otra vez en 90 días. Por encima del 10% significa que tus criterios de aceptación no corren en CI y estás financiando los mismos arreglos una y otra vez.

Estas tres van al lado de las métricas de rendimiento, no en su lugar. Pero cuando el crecimiento orgánico se estanca, suelen explicarlo antes que otro rastreo, que es la razón por la que las incluyo en toda consultoría SEO antes de tocar el sitio.

La pregunta de las herramientas, respondida en corto

Usa lo que ya use tu equipo de desarrollo. Jira, Linear, Asana, un tablero compartido: da igual.

Lo que sí importa: el backlog SEO tiene que vivir en el sistema de registro de desarrollo, no en una herramienta paralela de marketing. Un segundo gestor que los programadores no abren garantiza que el trabajo SEO sea invisible en la reunión donde se reparte la capacidad. Es justo lo contrario de lo que necesitas.

El software específico de gestión SEO resuelve reporting y visibilidad, que son problemas reales para agencias con muchos clientes. No resuelve la aceptación, que es el problema de los equipos internos con un solo sitio. Diagnostica qué problema tienes antes de comprar nada.

La buena gestión de proyectos SEO no tiene glamour. Es un backlog puntuado, tickets que un programador puede estimar, una porción estable de capacidad de sprint y la verificación de que el cambio está realmente en vivo. Clava eso y la estrategia que ya tienes empezará a dar resultados. Sáltatelo y ningún roadmap, herramienta ni consultor SEO freelance salvará el programa.

Preguntas frecuentes

¿Qué es la gestión de proyectos SEO?

La gestión de proyectos SEO es el proceso de convertir recomendaciones de búsqueda en cambios que están vivos en producción. Incluye dimensionar el trabajo, puntuarlo por impacto de negocio, secuenciarlo según la capacidad de desarrollo, escribir tickets que un programador acepte y verificar que el cambio sobrevivió al despliegue. La restricción que lo distingue es que SEO casi nunca controla el código que necesita cambiar, así que el trabajo es tanto negociación como planificación.

¿Qué hace un project manager SEO?

Un project manager SEO convierte la estrategia en un backlog priorizado y estimado, y después defiende ese backlog en la planificación de sprint. En el día a día significa traducir hallazgos de auditoría a tickets legibles para desarrollo, puntuar cada uno por proximidad a ingresos y esfuerzo técnico, perseguir la aceptación más que la entrega, e informar de lo que realmente se ha implementado. El rol existe porque estrategia y ejecución SEO suelen vivir en departamentos distintos.

¿Cómo se gestiona un proyecto SEO?

Convierte la auditoría en un inventario de tickets, puntúa cada ítem por proximidad a ingresos y días-desarrollador, escribe cada ticket con un paso de reproducción y un criterio de aceptación, negocia un porcentaje fijo de cada sprint en lugar de favores puntuales, define terminado como verificado en producción y revisa de nuevo a los 30 días. La secuencia importa más que la herramienta: un backlog puntuado y bien escrito avanza en cualquier gestor.

¿Qué herramientas hacen falta para gestionar proyectos SEO?

Las que ya use tu equipo de desarrollo. Comprar software específico de gestión SEO casi nunca resuelve un problema de entrega, porque el cuello de botella es la aceptación del ticket en el sistema de registro de desarrollo, no la visibilidad de tareas en una herramienta de marketing. Un segundo gestor que desarrollo no abre empeora el problema en lugar de arreglarlo.

¿Cuánto dura un proyecto SEO?

Google Search Central indica que un sitio puede tardar de cuatro meses a un año en beneficiarse de las mejoras SEO, y ese reloj arranca cuando el cambio se publica, no cuando se recomienda. En la práctica el retraso de implementación es la variable mayor: una corrección que espera seis meses en el backlog empuja un resultado de doce meses al año siguiente. Medir el tiempo hasta publicar suele ser más diagnóstico que medir el tiempo hasta posicionar.