Decisión de arquitectura
Compara opciones de URL, navegación, paginación, facetas o internacionalización con las restricciones del CMS y el inventario que debe conservarse.
Technical SEO Advisory
Asesoría SEO técnica
Convierte un problema técnico de búsqueda en evidencia, una decisión documentada y criterios de aceptación que el equipo pueda llevar a producción.
Criterio antes de programar
Un ticket técnico necesita explicar el comportamiento observado y la condición que demostraría una corrección
Muchas recomendaciones de SEO llegan a ingeniería como una frase suelta: mejorar el rastreo, corregir el renderizado o arreglar las etiquetas canonical. La persona que debe implementar todavía tiene que descubrir qué URL falla, cómo reproducir el problema y qué resultado se espera. Esa ambigüedad produce rondas de preguntas y cambios difíciles de validar.
La asesoría SEO técnica de Francisco se concentra en esa zona de decisión. Reúne evidencia, compara opciones con las restricciones de la plataforma y prepara requisitos que desarrollo, producto y marketing puedan discutir antes de publicar.
Alcance de la asesoría
La pregunta pendiente determina la investigación
La asesoría funciona mejor cuando el equipo ya tiene una decisión, un incidente o un cambio en preparación. Si necesita descubrir qué ocurre en todo el sitio, la auditoría SEO ofrece un diagnóstico acotado. Cuando existe una lista de trabajo y falta criterio para implementarla, la asesoría puede acompañar las decisiones sin repetir el rastreo completo en cada sesión.
Incidente de indexación
Delimita qué cambió, qué conjunto de páginas resultó afectado y qué señales permiten separar un fallo técnico de una decisión de selección de Google.
Cambio de plantilla
Revisa HTML inicial, contenido renderizado, enlaces, metadatos, datos estructurados y estados de error antes de convertir una observación en un requisito.
Migración o despliegue
Prepara controles para mapeos, redirecciones, enlaces internos, canonical, sitemaps y seguimiento, con responsables distintos para aprobar, publicar y validar.
Método de trabajo
La recomendación conserva la evidencia desde la pregunta hasta producción
El formato cambia según el equipo, aunque cada decisión necesita una cadena comprobable. Francisco documenta lo observado, el límite de la investigación y la condición que permitirá aceptar o rechazar la implementación.
1
Delimitar la pregunta
Se identifica el conjunto de URL, la fecha del cambio, el entorno afectado y la decisión que debe tomar el equipo. Una caída general y un error de plantilla requieren muestras diferentes.
2
Reunir evidencia
La revisión puede combinar respuestas HTTP, HTML, renderizado, rastreos, Search Console, analítica, registros y cambios de código. Cada fuente responde una parte de la pregunta.
3
Preparar la decisión
Las opciones incluyen dependencias, riesgo de regresión, persona responsable y criterio de aceptación. Ingeniería recibe el detalle técnico sin perder el motivo comercial.
4
Validar la salida
Después del despliegue se comprueba la respuesta publicada y se registra cualquier diferencia. La validación no convierte una mejora posterior de tráfico en causalidad automática.
Rastreo e indexación
El inventario de URL tiene prioridad sobre una consigna genérica de crawl budget
Antes de hablar de presupuesto de rastreo, conviene saber cuántas URL útiles existen y qué genera las demás. La documentación de Google reserva su guía de crawl budget para sitios grandes o con cambios frecuentes. En un sitio menor, la investigación suele empezar por estados HTTP, enlaces internos, duplicados, canonical, sitemaps y páginas que no aportan una intención propia.
La asesoría separa descubrimiento, rastreo, renderizado, selección canonical e indexación. Search Console puede indicar que una URL no está indexada, pero el motivo necesita contraste con la respuesta HTTP publicada y las señales de la página. Esta separación evita recomendar más enlaces o más capacidad de servidor cuando el problema está en otro punto.
Evidencia habitual
Controles que permiten reproducir el problema
- Muestra de URL afectadas y comparación con páginas que funcionan.
- Estado HTTP, encabezados, robots, canonical y presencia en sitemap.
- Ruta de enlaces internos y profundidad desde una página indexable.
- Patrones de parámetros, facetas, paginación o duplicación.
- Datos de Search Console con periodo y segmento definidos.
- Registros del servidor cuando están disponibles y el caso los necesita.
JavaScript y plantillas
El HTML recibido y el DOM renderizado responden preguntas diferentes
Google explica que sus sistemas rastrean, renderizan e indexan aplicaciones con JavaScript en fases distintas. También recomienda estados HTTP significativos y advierte sobre los soft 404 en aplicaciones con rutas del lado del cliente. La revisión sigue esas distinciones de las directrices oficiales de JavaScript SEO sin asumir que ejecutar JavaScript garantiza que todo contenido será elegido para el índice.
Una comparación útil registra el HTML inicial, el resultado renderizado y los recursos que fallaron. Luego se revisan enlaces, contenido principal, metadatos y datos estructurados en ambos estados. Si el problema depende de una interacción, una sesión o una API privada, el alcance deja constancia antes de proponer renderizado en servidor o cambios de plantilla.
Requisito para desarrollo
Qué debe contener un ticket técnico
- URL y plantilla afectadas, con pasos para reproducir.
- Comportamiento actual observado en una fecha y entorno concretos.
- Comportamiento esperado y motivo de búsqueda.
- Dependencias de datos, diseño, seguridad o infraestructura.
- Criterio de aceptación que pueda probarse después del despliegue.
- Plan de reversión cuando el riesgo del cambio lo justifique.
Migraciones
El control empieza con un mapeo y termina después del lanzamiento
Una migración exige inventariar URL antiguas y nuevas antes de configurar redirecciones. La guía de Google para cambios de sitio con URL nuevas recomienda redirecciones permanentes del servidor, actualización de canonical y sitemaps, pruebas y seguimiento posterior. La asesoría convierte esos principios en controles adaptados al CMS y al calendario de lanzamiento.
Francisco revisa muestras por tipo de página y conserva las excepciones que no caben en una regla global. El responsable técnico aprueba el mecanismo, mientras producto y contenido deciden qué inventario debe mantenerse, consolidarse o retirarse. No se promete una migración sin variación de tráfico, porque la selección e interpretación de las URL también dependen de sistemas externos.
Antes del cambio
Inventario, mapeo, dependencias, baseline, entorno de pruebas y lista de controles que pueden bloquear el lanzamiento.
Durante el lanzamiento
Estados HTTP, redirecciones, canonical, robots, enlaces internos, sitemap y muestras críticas verificadas en la salida pública.
Después del lanzamiento
Rastreo de comparación, Search Console, registros, analítica y resolución de excepciones con una persona responsable.
Buen encaje
Equipos con una decisión técnica y capacidad para implementar
- Ingeniería necesita requisitos o criterios de aceptación antes de programar.
- Existe un incidente de rastreo, renderizado o indexación que debe delimitarse.
- Una migración o cambio de plantilla necesita revisión en hitos concretos.
- El equipo interno quiere contrastar una propuesta de proveedor o plataforma.
- Producto necesita priorizar deuda técnica frente a otros riesgos.
Otro alcance
Problemas que requieren diagnóstico amplio o ejecución recurrente
- El sitio todavía no tiene un inventario fiable de problemas técnicos.
- No existe capacidad ni permiso para implementar recomendaciones.
- La expectativa depende de posiciones, ingresos o fechas garantizadas.
- Se necesita producción continua de contenido o adquisición de enlaces.
- La empresa busca delegar todas las decisiones de producto o seguridad.
Una investigación amplia puede empezar con la auditoría SEO. Si el reto es mantener un backlog y coordinar varios roles, el equipo de crecimiento integrado responde mejor a una relación recurrente.
Preguntas frecuentes
Responsabilidades y límites antes de empezar
¿En qué se diferencia la asesoría técnica de una auditoría SEO?
Una auditoría examina un alcance definido y entrega un diagnóstico priorizado. La asesoría técnica acompaña decisiones concretas antes y durante la implementación, revisa propuestas, responde preguntas de ingeniería y valida el cambio publicado. Si todavía no existe un inventario fiable de problemas, la auditoría suele ser el primer paso.
¿La asesoría incluye desarrollo?
El alcance puede incluir ejemplos, requisitos y revisión de código, pero no presupone que Francisco tenga permiso para modificar el repositorio o publicar. La responsabilidad de implementar se acuerda por tarea y la empresa conserva sus controles de ingeniería, seguridad y producto.
¿Qué acceso necesita la investigación?
Depende del problema. Puede requerir Search Console, analítica, rastreos, registros del servidor, plantillas, documentación de despliegues o un entorno de pruebas. Si un acceso no está disponible, la recomendación registra esa limitación y evita presentar una inferencia como observación.
¿Puede apoyar una migración de sitio?
Sí, con un alcance que cubra inventario de URL, mapeo, redirecciones, canonical, enlaces internos, sitemaps, controles previos y seguimiento posterior. El cliente conserva la decisión de lanzamiento y la operación de su infraestructura.
¿Con qué frecuencia se reúne el equipo?
La cadencia se ajusta a las decisiones y despliegues pendientes. Un incidente puede requerir una revisión concentrada, mientras una migración necesita controles en varios hitos. No se publica una frecuencia universal ni un tiempo de respuesta antes de definir el alcance.
¿Se garantizan mejoras de indexación, tráfico o Core Web Vitals?
No. La asesoría define evidencia, requisitos y validaciones dentro del acceso disponible. Los resultados también dependen de la implementación, la infraestructura, el contenido, la demanda y los sistemas de búsqueda, por lo que no se garantizan posiciones, tráfico, ingresos ni fechas.
Una consulta centrada en la decisión técnica pendiente
La consulta inicial revisa la pregunta, la evidencia disponible y quién puede implementar antes de definir el alcance.