Metodología de un proyecto SEO: fases, entregables y QA

El proyecto SEO que falla casi nunca lo hace por una mala auditoría. Falla un mes después, cuando el informe lleva decenas de hallazgos con la misma urgencia, desarrollo no sabe cuál es el primero y nadie anotó cuál era el tráfico de partida para poder comparar.

Aquí describo cómo organizo un proyecto de principio a fin: ocho fases, el entregable de cada una, qué le pido a desarrollo y a marketing, qué mido y qué hago cuando algo no cuadra. Las guías en español que revisé lo tratan sobre todo como gestión (alcance, calendario, informes) o como una lista de fases genéricas, y apenas detallan cómo se puntúa una prioridad o cómo se revierte un despliegue que sale mal. Si buscas la visión general del oficio, está en qué hace un consultor SEO; aquí voy al método.

Fase 1: descubrimiento y objetivos de negocio

Antes de abrir un rastreador necesito saber qué quiere el negocio, con qué datos se puede medir y qué puede cambiar de verdad. Las preguntas que hago en la primera reunión no son de SEO; cada una decide algo concreto más adelante.

Los accesos se piden pronto y con criterio. Google aconseja, para una auditoría, conceder solo acceso de lectura a Search Console. La ayuda de Search Console distingue propietario, usuario con todos los permisos y usuario restringido: el restringido ve solo parte de los datos, el de todos los permisos los ve todos y puede además enviar sitemaps o rechazar enlaces, y el propietario añade usuarios y cambia ajustes. Mi criterio es empezar con el nivel más bajo que me deja ver los datos que la auditoría necesita y pedir más solo cuando me toca implementar algo.

El entregable de esta fase es ese brief: objetivo y KPI principal, qué queda fuera del alcance, responsable de cada área y fecha de la primera revisión. Si el objetivo del negocio y los datos no cuadran, por ejemplo cuando quieren crecer en una línea que hoy casi no tiene demanda de búsqueda, lo digo aquí y no tres meses después.

Fase 2: auditoría y priorización

La auditoría cubre rastreo, indexación, códigos de respuesta, plantillas, contenidos y enlaces, y suma datos de campo como los Core Web Vitals. En un sitio grande añado el presupuesto de rastreo. Un informe de auditoría no es una lista de errores, es una lista de decisiones: cada hallazgo lleva una URL de ejemplo, el dato que lo prueba, el impacto estimado y lo que cuesta arreglarlo.

Para ordenar los hallazgos uso tres notas del 1 al 5. La fórmula es mía y sirve para ordenar la conversación, no para sustituir el criterio.

Ordeno por impacto multiplicado por confianza y dividido entre esfuerzo. Si dos tareas empatan, gana la que desbloquea a otra. El resultado cae en cuatro cuadrantes: hacer ya, planificar, aprovechar si sobra tiempo y aplazar.

Cuando un dato contradice a otro, no lo meto como hallazgo hasta entender por qué. Un caso habitual: el rastreo marca una URL como bloqueada y Search Console la muestra indexada. La guía de Google recuerda que robots.txt impide rastrear, no indexar, así que reviso la URL con Inspección de URL antes de proponer nada.

Fase 3: palabras clave, intención y arquitectura

El producto de esta fase no es una hoja con miles de términos. Es un mapa que asigna cada grupo temático a una sola URL, con su intención. Clasifico la intención mirando la página de resultados, no el volumen, porque una misma consulta puede pedir una guía en un sector y una ficha de producto en otro. Los volúmenes de las herramientas son estimaciones; los uso para ordenar, no como previsión de tráfico. En preguntas complejas añado además una estimación de las subconsultas que un buscador con IA puede lanzar, con el método de query fan-out.

El ejemplo es ilustrativo, no un cliente. La columna que más trabajo da es la última: detectar dos páginas que compiten por lo mismo y decidir cuál se queda. Si hay que partir de cero con un volumen grande de términos, ese es el alcance de un trabajo de keyword research.

Antes de proponer una estructura nueva compruebo si el problema se resuelve con la existente. La guía de inicio de Google dice que no hay que dejarlo todo y reorganizar el sitio de golpe, y yo lo aplico: reordeno solo lo que el mapa demuestra mal ubicado. Cuando la estructura sí es el problema, el trabajo pasa a ser de arquitectura web, con jerarquía, patrones de URL y mapa de redirecciones.

Fase 4: hoja de ruta y backlog

La hoja de ruta tiene dos niveles. El trimestral dice qué quiere lograr cada bloque de trabajo; el backlog lista las tareas, cada una con una ficha. La ficha es lo que permite que desarrollo trabaje sin pedirme una reunión por cada ticket.

Tarea:        Redirigir las URLs de la categoría antigua
Objetivo:     Conservar el tráfico de esa sección
Criterio:     Cada URL antigua responde 301 a su equivalente (lista adjunta)
Responsable:  Desarrollo
Revisa:       SEO, antes y después del despliegue
Entra en:     Sprint acordado con desarrollo
Se revierte:  Quitando la regla de redirección del servidor

Hay una regla que aplico más allá de las migraciones: un cambio importante por área y por periodo. Google lo dice con estas palabras para los cambios de dominio («change only one thing at a time»): primero mover el sitio y, como paso aparte, cambiar el diseño. Lo extiendo como criterio general porque, si cambias plantilla, títulos y arquitectura el mismo día y el tráfico se mueve, no vas a saber qué lo movió.

Fase 5: implementación y QA con desarrollo

Qué le pido a desarrollo

Escribo cada requisito como un comportamiento que se pueda comprobar y dejo la solución técnica a desarrollo. «Las URLs de la categoría antigua responden 301 a su equivalente y no pasan por más de un salto» es un criterio que desarrollo puede cumplir como prefiera y yo puedo verificar. «Pon una redirección en el .htaccess» obliga a conocer su servidor y no dice cuándo está terminado. Los matices entre códigos están en mi guía de tipos de redirección.

El entorno de pruebas va cerrado a buscadores. La documentación de Google indica que robots.txt sirve para impedir el rastreo y no la indexación, y que para lo segundo hay que usar noindex o pedir inicio de sesión. Mi preferencia es la contraseña, porque cubre las dos cosas, y no fiarme solo de robots.txt.

Checklist antes de desplegar

1. Códigos de respuesta de las URLs clave: 200 en las que siguen, 301 en las antiguas con equivalente y 404 real en las eliminadas.
2. Redirecciones sin cadenas ni bucles, probadas con la lista completa y no con tres ejemplos.
3. Canonical, título y descripción de cada plantilla, con una URL de muestra por tipo de página.
4. Que el noindex y los bloqueos de staging no han viajado a producción, un error clásico y caro.
5. El sitemap XML contiene las URLs nuevas y ninguna redirigida.
6. Rendimiento de las plantillas nuevas en móvil, medido antes y después.

Para verificar redirecciones en vivo me basta una línea. Este es el resultado que obtuve en un servidor local de pruebas con una regla 301:

curl -sI https://www.ejemplo.com/url-antigua/ | grep -iE '^(HTTP|location)'

HTTP/1.1 301 Moved Permanently
Location: /nueva/

En mi prueba la cabecera Location salió relativa porque así la envió el servidor local; la de tu servidor puede devolver una URL absoluta.

Antes de desplegar también acordamos qué síntomas paran el despliegue, por ejemplo redirecciones que devuelven 404 en URLs con tráfico, y quién decide. Esa conversación incómoda es la que casi ningún plan incluye.

Fase 6: contenido y enlazado

Cada página nueva o reescrita sale de un brief: intención, pregunta que debe resolver, URL destino, enlaces internos obligatorios y fuentes que hay que citar, más las evidencias de E-E-A-T que sostienen el texto (autoría, casos, datos propios). La guía de inicio de Google sostiene que crear contenido útil y atractivo probablemente influya más en un sitio que cualquiera de los otros factores que describe; por eso el contenido va después del diagnóstico técnico, pero no se queda en segundo plano.

Con marketing y contenido

El calendario editorial se ajusta a la capacidad real del equipo, no a la lista de keywords. Si el equipo publica cuatro piezas al mes, el plan tiene cuatro piezas al mes, elegidas por la nota de prioridad, y las demás esperan. También decido por tema si conviene actualizar lo que ya existe antes de crear algo nuevo, para no abrir una segunda página donde ya hay una.

El enlazado interno se planifica antes de publicar, con una matriz de origen y destino. Cómo la construyo y qué mido con ella está en la guía sobre la matriz de enlazado interno.

Fase 7: medición y reporting

La medición empieza antes de la primera tarea: guardo una captura del rendimiento de partida. El informe de rendimiento de Search Console agrupa los datos por consulta, página, país, dispositivo, apariencia en el buscador y fecha, y ofrece cuatro métricas: clics, impresiones, CTR y posición media. Los datos más recientes pueden ser preliminares y cambiar en las horas siguientes. El selector llega a 16 meses; en un proyecto largo exporto los datos para no depender de esa ventana.

Search Console y la analítica no tienen por qué coincidir: una cuenta clics en resultados y la otra sesiones en la web. Cuando las cifras difieren, no corrijo una con la otra; anoto qué mide cada una y uso Search Console para la búsqueda y la analítica para el negocio.

Cada informe acaba en una decisión que alguien puede tomar. A dirección le sirve saber si el plan va según lo previsto, qué riesgo hay y qué se le pide; un listado de consultas no le dice nada de eso. Desarrollo necesita errores concretos con su URL. Un gráfico que no pide nada a nadie es decoración.

Fase 8: iteración y mantenimiento

Cuando el tráfico baja, sigo el orden que propone Google en su guía para depurar caídas, con algún añadido mío. Primero miro si caen impresiones y clics o solo clics, porque lo segundo apunta a títulos, fragmentos o resultados enriquecidos de otros. Después amplío el rango a 16 meses para descartar estacionalidad, comparo periodos, filtro por tipo de búsqueda y ordeno las páginas por diferencia de clics. Si la caída afecta a todo el sitio reviso el informe de indexación; si solo afecta a algunas páginas, las inspecciono una a una. Y reviso rastreo, acciones manuales y problemas de seguridad.

La paciencia también es método. Google indica que algunos cambios surten efecto en horas y otros pueden tardar varios meses, y que lo razonable es esperar unas semanas antes de volver a analizar. Una validación de arreglos en el informe de indexación puede tardar unas dos semanas, o mucho más. Por eso fijo la fecha de revisión de cada tarea cuando entra en el backlog y no antes de lo que permite el rastreo.

Si la caída coincide con una actualización del algoritmo, el caso cambia de naturaleza y lo trato aparte; lo explico en mi guía sobre calidad y Core Updates. El mantenimiento es el mismo ciclo en pequeño: revisión mensual de indicadores y mini-auditorías trimestrales, una práctica que ya recomiendo en mi página de auditoría.

Tipos de proyecto y tiempos orientativos

Las ocho fases no pesan igual en todos los encargos. Esto es lo que cambia, con los plazos que publico en mis páginas de servicio cuando existen.

En una migración manda lo que Google documenta para los cambios de URL: preparar y probar el sitio nuevo, mapear las URL antiguas a las nuevas, usar redirecciones permanentes del lado del servidor, probarlas y vigilar el tráfico de los dos sitios. Las redirecciones hay que mantenerlas el mayor tiempo posible, generalmente al menos un año. En un sitio mediano, la documentación habla de unas semanas o más para que Google muestre las URL nuevas. El detalle con checklist y mapa lo desarrollo en la guía de migración SEO paso a paso.

Mis rangos para las fases, siempre orientativos: descubrimiento, una o dos semanas si los accesos llegan pronto; keywords y arquitectura, de dos a cuatro; hoja de ruta, una semana; implementación, de semanas a meses porque depende del calendario de desarrollo y no del SEO. En mi página de consultoría escribo que el SEO necesita entre 6 y 12 meses para consolidar resultados. Es una estimación de oficio mía; Google no publica plazos y yo no los prometo.

Errores típicos de un proyecto SEO

• Sin acceso técnico. El análisis llega, pero nadie puede implementarlo. Si el CMS, el servidor o el repositorio están fuera de alcance, lo digo en la fase 1 y el plan se limita a lo que sí se puede tocar.
• Sin priorizar. Cuarenta tareas con la misma urgencia equivalen a ninguna prioridad.
• Sin medir el punto de partida. Sin una captura previa no puedes demostrar qué cambió.
• Cambiar demasiado a la vez. Si todo cambia el mismo día, ninguna variación se puede atribuir.
• Informes que no piden nada. Gráficos correctos sin una decisión al final.
• Tareas sin dueño. Sin un nombre y una fecha, la tarea no se hace.

Cómo lo trabajo yo: lo publicado y lo que no

Los resultados que cito son los de mis casos de éxito, con sus propios datos. En el de Atida, la migración de los dominios .es y .pt al .com figura con 0 % de pérdida de tráfico orgánico durante el proceso. En el de Nedgia, el caso publica un 75 % más de tráfico orgánico en los seis meses posteriores a la migración. En el de Cloudworks, la visibilidad se multiplicó por 30 en 12 meses. No añado más cifras que esas.

Sobre el propio blog sí puedo hablar con datos medidos, y están en la guía de enlazado: una matriz de origen y destino, un rastreo propio con 47 artículos y una mediana de 5 enlaces entrantes desde otros artículos; la primera medición, antes de enlazar los textos nuevos desde los antiguos, encontró tres sin ninguno.

En cuanto a herramientas, el código muestra que la web verifica Search Console con una etiqueta meta y declara dos sitemaps en el robots.txt. Los identificadores de Google Analytics 4, Google Tag Manager y Microsoft Clarity están previstos en la configuración pero desactivados, y tampoco hay verificación de Bing Webmaster Tools. Hoy mi propio sitio se mide con Search Console y con mi rastreo local, y no con analítica web.

Cómo comprobar que tu proyecto SEO está bien llevado

Estas ocho preguntas sirven para un proyecto mío o de cualquier otra persona, interna o externa. Si no sabes responder a tres o más, falta método.

1. ¿Existe un brief con un objetivo, un KPI y lo que queda fuera del alcance?
2. ¿Se guardó el estado de partida de Search Console antes de tocar nada?
3. ¿Cada hallazgo de la auditoría tiene una URL de ejemplo, un dato y una prioridad?
4. ¿Hay un máximo claro de tareas para el primer trimestre?
5. ¿Cada tarea tiene responsable con nombre, criterio comprobable y forma de revertirla?
6. ¿Existe un checklist de despliegue y alguien de SEO disponible el día de la salida?
7. ¿Cada informe acaba en una decisión y tiene un lector concreto?
8. ¿Hay fechas de revisión que respetan lo que tarda Google en reflejar los cambios?

Si quieres que revise un proyecto en marcha con estos criterios, es parte de lo que hago en una auditoría.

Preguntas frecuentes

Referencias y fuentes

Documentación consultada para este artículo.

1. Guía de optimización para motores de búsqueda (SEO Starter Guide) Google Search Central
2. Do you need an SEO? Google Search Central
3. Get started with Google Search Google Search Central
4. Site moves with URL changes Google Search Central
5. Debugging drops in Google Search traffic Google Search Central
6. Performance report (Search results) Ayuda de Search Console
7. Page indexing report Ayuda de Search Console
8. Search Console: owners, users and permissions Ayuda de Search Console