Servicio técnico · SEO técnico y auditoría
SEO técnico: cuando la web está bien por fuera y Google no puede leerla por dentro
Hay webs bien hechas, con buen contenido y marca trabajada, que no crecen. No les falta trabajo: les falta que el buscador pueda entrar, entender y guardar lo que ya tienen.
- Revisión hecha por una persona, no una exportación de herramienta
- Orden de corrección según el impacto, no alfabético
- Comprobación posterior: si el cambio no se nota, se dice
Pensado para webs con recorrido: comercio electrónico, proyectos en dos idiomas y sitios con años de contenido.
Ejemplo ilustrativo · fichas ficticias, no resultados prometidos
El problema real
Una web puede tener buen contenido y seguir invisible si el buscador no puede rastrearla bien
Cuando una empresa invierte en contenidos durante meses y el tráfico no se mueve, la conclusión fácil es que hay que escribir más. A menudo el texto ya es lo bastante bueno y lo que falla es la capa de debajo: el buscador entra menos de lo que debería o no llega a ver la mitad de lo que has puesto.
Páginas buenas que no acaban en el índice
Google las descubre, entra y aun así no las guarda. En Search Console aparecen como rastreadas y no indexadas. Es el síntoma que más se ignora: no hace daño a ninguna cifra, simplemente no pasa nada.
Varias direcciones compitiendo por el mismo tema
Una categoría, un filtro, una página antigua y un artículo nuevo hablan de lo mismo y ninguno acaba de ganar. El problema no es el contenido: es que nadie ha decidido cuál debe ser la buena.
Señales contradictorias sobre qué página manda
La etiqueta canonical dice una cosa, el mapa del sitio otra, las redirecciones una tercera y los enlaces internos una cuarta. Cuando hay contradicción, elige Google, no tú.
Mapas del sitio que hacen perder el tiempo
El archivo que debería ser la lista limpia de lo que quieres que se mire trae direcciones viejas, redirigidas o bloqueadas. En vez de orientar, despista.
Dos idiomas que no se dan la mano
Las dos versiones existen pero no se señalan la una a la otra como toca. El buscador acaba enseñando la versión equivocada en el país equivocado, o descarta una por parecerle repetida.
Lo que tú ves no es lo que recibe el buscador
Plantillas pesadas, bloques montados con código del navegador y capas de caché pueden servir una versión al visitante y otra al robot. Es lo más difícil de ver: para ti la web se ve perfecta.
El punto en común de los seis: no se ven navegando por la web. Se ven comparando lo que la web sirve con lo que el buscador dice que ha recibido.
Definición útil
Qué es el SEO técnico y por qué los problemas de SEO técnico no se ven mirando la web
El SEO técnico se ocupa de que un buscador pueda entrar en la web, recibirla entera, entenderla y decidir guardarla. No escribe textos ni consigue enlaces: prepara el terreno para que cuenten.
La documentación de Google describe la búsqueda en tres etapas: el rastreo, que es descubrir qué páginas existen; la indexación, que es analizar el texto, las imágenes y el vídeo y guardar la información en el índice; y la publicación de resultados, que es elegir qué se enseña ante una consulta. Un problema técnico siempre es algo que rompe una de estas etapas antes de que tu trabajo llegue a la siguiente.
Es útil por una razón práctica: si el rastreo falla, todo lo demás es gasto. Puedes contratar contenidos, enlaces y campañas, y el buscador seguirá sin ver lo que has pagado.
Lo que sí es SEO técnico
Acceso del robot, direcciones, duplicados, idiomas, mapas del sitio, redirecciones, cómo se monta la página, velocidad real en móvil, arquitectura, enlaces internos y datos estructurados.
Lo que no lo es, aunque lo parezca
Decidir de qué habla la web, escribirla, ganar autoridad o trabajar la marca. Son disciplinas vecinas, pero con otro trabajo y otro calendario.
La frontera que molesta
Los hay que parecen de contenido y son técnicos —dos páginas compitiendo— y al revés —una página que nadie indexa porque no dice nada nuevo. Separarlos es la mitad del trabajo.
Qué cambia la manera de hacerlo
Pasar una herramienta no es auditar: exportar errores no dice qué hay que arreglar primero
Cualquier rastreador comercial devuelve cientos de líneas en media hora. El problema de esa hoja no es que sea falsa: es que trata igual una etiqueta repetida y una página de venta fuera del índice, y deja la decisión difícil —el orden— a quien no tiene criterio para tomarla.
Qué pasa
Qué dirección, qué respuesta del servidor, qué dice Search Console, qué ve el rastreador y en qué se contradicen. Sin la prueba, un punto de informe es una opinión.
Por qué pasa
Suele ser la consecuencia de una plantilla, un conector, una regla del servidor o una decisión de arquitectura tomada hace años. Si se arregla la página y no la causa, vuelve sola.
Cuánto pesa
Un error en cuatro páginas sin tráfico y uno en la plantilla de todo el catálogo no son comparables. El peso se calcula con páginas afectadas, valor comercial y esfuerzo de corrección.
Una revisión técnica útil no acaba en una lista de errores: acaba en una lista de decisiones, ordenada, con la prueba de cada una al lado.
La diferencia se nota el día que alguien tiene que ejecutarlo. Una hoja con cuatrocientos avisos no se hace nunca; una lista corta de puntos ordenados se sabe por dónde cogerla. El trabajo no es encontrar errores —eso lo hace una herramienta— sino reducirlos a las pocas cosas que cambian algo.
Alcance
Los bloques que se revisan, y qué busca cada uno
No todos los bloques pesan igual. En un comercio electrónico con filtros, los duplicados y el rastreo se llevan la mitad del trabajo; en una web corporativa de cincuenta páginas, casi todo se juega en cómo se monta la página y en el enlazado interno.
Rastreo y acceso del robot
Robots.txt, respuestas del servidor, cadenas de redirecciones, páginas huérfanas y zonas que consumen visitas sin aportar nada. Con registros del servidor si hace falta.
Indexación y cobertura
Estado de cada dirección en Search Console y la comprobación más olvidada: que lo que quieres fuera esté fuera y que lo que quieres dentro esté dentro.
Duplicados, etiquetas canonicals y redirecciones
Qué dirección quieres que gane y qué señales la contradicen: variantes con y sin www, filtros, ordenaciones y búsqueda interna.
Idiomas y mercados
Si las versiones están conectadas de forma recíproca, si hay una versión de reserva declarada y si los enlaces internos se quedan dentro de su idioma.
Mapas del sitio y archivos de control
Que el mapa contenga exactamente lo que quieres que se mire y que no contradiga las etiquetas canonicals de las páginas que lista.
Cómo se monta la página
Qué hay en el código servido y qué se añade después con código del navegador, y si el robot llega a los archivos que necesita para montarla entera.
Velocidad y experiencia en móvil
Las tres métricas de Core Web Vitals con datos reales de usuario y las causas: imágenes, tipografías, código que bloquea la pintura y conectores inútiles.
Arquitectura y enlazado interno
Cuántos pasos hay desde la página de inicio hasta lo que vende, qué páginas concentran enlaces y cuáles no reciben ninguno.
Datos estructurados
Si el marcado existe, si es válido y si describe lo que la página enseña de verdad o solo se ha puesto porque un conector lo generaba solo.
Cambios de dirección y migraciones
Si ha habido un cambio reciente de dominio, de plataforma o de estructura de direcciones, se revisa qué se ha perdido por el camino. Suele ser el punto donde más tráfico desaparece de golpe.
Profundizamos · bloque 1
Rastreo e indexación: que el buscador entre no significa que te guarde
Son dos procesos diferentes y se confunden cada día. Una página puede ser rastreada cien veces y no estar nunca en el índice, y saber en cuál de las dos puertas te has quedado cambia el trabajo que toca.
Cuántas visitas recibe tu web y de qué dependen
Google explica que la frecuencia con la que rastrea un sitio sale de un límite de capacidad, para que el rastreo no tumbe tu servidor, y de una demanda de rastreo, que depende del interés que tenga en volver a mirarte.
La misma documentación avisa de que esto solo es serio en casos concretos: sitios del orden de un millón de páginas únicas con contenido que cambia cada semana, sitios a partir de unas diez mil páginas con contenido que cambia cada día, y sitios con muchas direcciones clasificadas en Search Console como descubiertas y actualmente sin indexar. Si tu web tiene doscientas páginas, el presupuesto de rastreo no es tu problema, y quien te lo venda como tal te está vendiendo trabajo que no te corresponde.
Lo que sí es problema tuyo, a cualquier tamaño, es dónde gasta el buscador las visitas que te dedica. Filtros con miles de combinaciones, búsquedas internas indexables y paginaciones sin freno lo hacen pasar el día en zonas que no venderán nunca nada.
La trampa del robots.txt, y por qué cuesta tan caro
El robots.txt le dice al rastreador a qué direcciones puede acceder, y existe sobre todo para no saturar tu servidor. Google lo dice con todas las letras: no es un mecanismo para mantener una página fuera de Google. Una dirección bloqueada ahí puede seguir saliendo en los resultados si otros sitios enlazan a ella, solo que sin descripción.
De aquí viene el error más caro y más repetido. Si quieres que una página no se indexe, le pones una regla noindex; pero para que el rastreador la vea, la página no puede estar bloqueada en el robots.txt. Si la bloqueas y le pones noindex a la vez, el robot nunca entra, nunca lee la regla, y la página se queda fuera de control.
La comprobación es de dos minutos: listar qué bloquea el robots.txt y cruzarlo con qué lleva noindex. Cuando las dos listas se tocan, casi siempre hay una página que alguien quiere fuera y que en realidad está dentro, o al revés.
Rastreada, actualmente sin indexar
Google ha entrado y ha decidido no guardarla. Suele significar que no aporta nada que no tengas ya en otra página.
Descubierta, actualmente sin indexar
Google sabe que existe pero todavía no ha entrado. Cuando hay muchas, el problema suele ser de capacidad del servidor o de exceso de direcciones.
Duplicada sin canonical declarada
Google la considera repetida de otra. Si crees que no lo son, el trabajo es hacer que el contenido sea claramente diferente.
Google ha elegido una canonical diferente
Has declarado cuál quieres y Google ha elegido otra. Suele señalar una contradicción entre la etiqueta, las redirecciones y los enlaces internos.
Profundizamos · bloque 2
Duplicados, canonicals y migraciones: qué dirección quieres que gane cuando hay varias
Toda web medianamente grande tiene la misma página en más de una dirección: filtros, ordenaciones, parámetros de campaña, migraciones mal cerradas. El error no es eso: es no haber dicho nunca cuál es la buena.
Las señales no valen lo mismo, y este es el matiz que se pierde
Google ordena explícitamente la fuerza de los métodos para indicar qué dirección es la canónica. Las redirecciones son una señal fuerte de que el destino debe ser la página buena. La etiqueta canónica también. Y la inclusión en el mapa del sitio es una señal débil: ayuda, pero no decide.
Dos consecuencias. Poner una dirección en el mapa del sitio no la convierte en la principal, y mucha gente confía en ello como si lo hiciera. Y una redirección apuntando hacia un lado con una etiqueta canónica apuntando hacia el otro son dos señales fuertes opuestas: el resultado es imprevisible.
Google también recomienda elegir un solo lugar para declarar la etiqueta canónica: o en el HTML o en la cabecera, no las dos a la vez, porque es fácil acabar declarando una dirección diferente en cada lado.
Y un recordatorio que ahorra discusiones: la etiqueta es una indicación, no una orden. Google puede elegir otra si le parece más completa, y entonces la respuesta no es insistir, sino mirar por qué las dos páginas se parecen tanto.
Migraciones: el día que más se pierde y más se puede salvar
Un cambio de dominio, de plataforma o de estructura de direcciones es el momento de más riesgo de la vida de una web, y el único donde un buen trabajo técnico se nota en semanas en lugar de meses.
- Redirecciones del lado del servidor. Los códigos 301 y 308 indican que la página se ha movido para siempre. Google acepta también el meta refresh a cero segundos, y deja la redirección hecha con código del navegador como último recurso, solo cuando no se puede hacer de ninguna otra manera.
- Un paso, no tres. Las cadenas de redirecciones se cortan apuntando el origen directamente al destino final.
- Mantenerlas mucho tiempo. Google recomienda conservarlas como mínimo un año: es el tiempo que necesita para trasladar las señales y volver a rastrear los enlaces que otros sitios tienen hacia tus direcciones antiguas.
- Mover por partes cuando se puede. Empezar por una sección que cambie poco permite ver qué pasa antes de jugárselo todo.
- Marcar la fecha. Un cambio grande se anota en un calendario de medición, para que dentro de tres meses se pueda distinguir una caída causada por la migración de cualquier otra cosa.
Profundizamos · bloque 3
Dos idiomas, dos mercados: qué debe ver el buscador y qué ve de verdad
Cualquier web con versión en castellano y en catalán, o que hable a más de un mercado de habla hispana, se juega una parte nada pequeña del tráfico en algo que no se ve: las etiquetas que conectan cada versión con su hermana.
Google admite tres formas equivalentes de declararlo —en el HTML, en las cabeceras de la respuesta o dentro del mapa del sitio— y deja elegir la más cómoda de mantener. En webs grandes, la que suele dar menos problemas es el mapa del sitio: se genera solo y no depende de que cada plantilla haga bien su parte.
La regla que más se rompe es la de la reciprocidad: si la página en castellano señala la catalana, la catalana debe señalar la castellana. Cuando una web añade un idioma nuevo, lo más habitual es que nadie vuelva atrás a completar el enlace en sentido contrario. Google recomienda expresamente enlazar de forma bidireccional las versiones nuevas con la versión que ya tiene fuerza, no solo las nuevas entre ellas.
Y hay una etiqueta que casi nadie pone: la versión por defecto para cualquier idioma que no tengas declarado. Sin ella, un visitante de un país que no has previsto acaba en la versión que el buscador considere.
Los tres síntomas que delatan el problema
Tráfico de un país con la página del idioma equivocado; una de las versiones sistemáticamente fuera del índice; o las dos saliendo a la vez por la misma consulta.
Lo que no arregla el problema
Traducir más páginas. Si la conexión entre versiones está rota, cada traducción nueva suma al problema. Primero se cierra la conexión, después se traduce.
El detalle que se come horas
Los enlaces internos. Una web donde el menú, el pie o las listas de relacionados saltan de idioma acaba enviando al buscador —y al visitante— a la otra versión a media lectura. Se comprueba enlace por enlace, no por muestreo.
Profundizamos · bloque 4
Renderizado: lo que ve tu navegador y lo que recibe el buscador pueden no coincidir
Es el bloque que más sorpresas da y el que menos se revisa: para comprobarlo no sirve abrir la web, hay que pedir la página como la pediría un robot.
Cómo procesa Google una página que se monta con código
Google explica que trata las aplicaciones web con JavaScript en tres fases: rastreo, renderizado e indexación. Las páginas hacen cola tanto para ser rastreadas como para ser renderizadas, y desde fuera no se puede saber en qué cola está una página concreta. El renderizado lo hace con una versión siempre actualizada de Chromium: la capacidad está; la certeza de que ocurra enseguida, no.
La consecuencia de negocio: todo lo que solo existe después de ejecutar código del navegador llega más tarde y con menos certeza que lo que ya viene en el código servido. En una ficha de producto, el precio y la descripción vale más que estén en el HTML inicial.
Y un detalle que pasa desapercibido: Google no renderiza código de archivos bloqueados. Si el robots.txt cierra la carpeta de los estilos o de los scripts, el buscador monta una página incompleta y la juzga así.
La caché, la otra fuente de discrepancias
En las webs con caché de página completa, el servidor puede estar entregando una versión guardada hace días. Esto es bueno para la velocidad, hasta que esa versión contiene una etiqueta antigua, una redirección que ya no debería estar o un bloque que se ha cambiado.
De ahí un malentendido habitual: se hace un cambio, se comprueba y parece que no ha pasado nada, pero lo que se está mirando es la copia guardada. La comprobación solo vale pidiendo la página de nuevo, sin caché ni sesión iniciada.
La prueba que resuelve la mayoría de estos casos: pedir el HTML en bruto de la página y buscar en él el texto que debería aparecer. Si no está, el visitante lo ve y el buscador no, y todo lo que venga después está construido sobre una página que Google todavía no tiene entera.
Profundizamos · bloque 5
Velocidad, móvil y Core Web Vitals: qué cifras se miran y cuáles no quieren decir nada
Es la parte del SEO técnico con más ruido alrededor: una nota que todo el mundo mira y que no es ninguna de las métricas que cuentan, y tres cifras que sí cuentan y que casi nadie lee bien.
Pintado del contenido principal
Mide cuándo aparece el elemento grande de la página. El umbral de buen rendimiento es 2,5 segundos o menos. Es la que más a menudo se arregla tocando imágenes, tipografías y orden de carga.
Respuesta a la interacción
Mide cuánto tarda la página en reaccionar cuando alguien toca en ella. Lo bueno es 200 milisegundos o menos; entre 200 y 500 se considera mejorable y por encima de 500, malo. Suele delatar exceso de código en cada clic.
Estabilidad visual
Mide cuánto se mueve el contenido mientras carga. El umbral es 0,1 o menos. Es la que más molesta al usuario y la más barata de arreglar: suele bastar reservando el espacio de las imágenes.
El umbral que cambia la conversación
Las tres cifras no se miran sobre la media, sino sobre el percentil 75 de las cargas, y separadas por móvil y escritorio: una página va bien cuando tres de cada cuatro visitas van bien en ella. Por eso una web puede ir muy rápida en el portátil de la oficina y estar suspendida.
Y una aclaración que ahorra frustración: la nota sobre cien de una herramienta de laboratorio no es ninguna de las tres métricas. Sirve para encontrar causas y comparar dos versiones de una misma página, no para saber si estás aprobado.
Móvil, que ya no es una versión alternativa
Google indexa y clasifica con su agente de teléfono inteligente. No es que el móvil sea importante: el móvil es la versión que se juzga. Cuando una web esconde bloques en pantallas pequeñas para ganar velocidad, los esconde al buscador.
Mejorarlo a fondo es un trabajo propio, con sus horas. Cuando la revisión detecta que este es el bloque que más pesa, el camino natural es el servicio de optimización de velocidad web.
Profundizamos · bloque 6
Arquitectura y enlazado interno: dónde se queda la autoridad que ya tienes
El enlazado interno es la única palanca de autoridad que controlas del todo: no depende de que nadie quiera enlazarte, sino de cómo repartes por dentro la fuerza que ya tienes.
La revisión mira tres cosas: a cuántos pasos de la página de inicio está lo que vende, porque una categoría a cinco clics recibe menos visitas del buscador; qué páginas concentran enlaces y cuáles no reciben ninguno, porque en toda web con años de historia hay contenido bueno no enlazado desde ningún sitio; y qué dicen los textos de los enlaces, porque un menú donde todo se llama «Ver más» no informa de nada.
El mapa del sitio entra aquí como herramienta de control, no como solución. Debe contener exactamente lo que quieres que se mire y respetar los límites del formato —un máximo de 50 MB sin comprimir o 50.000 direcciones por archivo, partiéndolo en varios si hace falta. Un mapa con direcciones redirigidas o bloqueadas no es neutro: resta credibilidad a toda la lista.
Páginas huérfanas
Existen, están publicadas y no reciben ningún enlace desde dentro. Se encuentran cruzando el rastreo con el mapa del sitio y con las direcciones que reciben impresiones. Suele ser el hallazgo que más valor recupera con menos trabajo.
Consultas repartidas entre páginas tuyas
Cuando la misma búsqueda muestra tres direcciones tuyas, el buscador no sabe cuál es la respuesta. El trabajo no es siempre eliminar: a menudo es decidir cuál manda y reorientar las demás.
Paginaciones y listados infinitos
Catálogos con cientos de combinaciones de filtros hacen que el rastreo se pierda en páginas que nunca se posicionarán. Se decide cuáles se abren y cuáles se cierran, de forma coherente con la etiqueta canónica.
Profundizamos · bloque 7
Datos estructurados: qué hacen, qué no hacen y por qué ahora importan más
Es el bloque donde más se promete y menos se cumple. El marcado sirve, pero no para lo que la mayoría de la gente cree.
Lo que Google dice literalmente
Google afirma que no garantiza que tus datos estructurados aparezcan en los resultados, aunque la página esté marcada correctamente según su propia herramienta de prueba. La formulación exacta es que usar datos estructurados permite que una funcionalidad esté ahí, no garantiza que lo esté.
Poner marcado no es comprar un resultado destacado: es ponerse en condiciones de tenerlo y, a menudo más importante, declarar en un formato que las máquinas entienden qué es cada cosa de tu web.
La regla no admite excepciones: el marcado solo puede afirmar lo que la página enseña. Declarar una persona que no aparece en ningún sitio o unas valoraciones que no se ven no es optimizar: es una incoherencia que acaba costando credibilidad.
Por qué el contexto ha cambiado
Con los resúmenes generados por inteligencia artificial y los asistentes que leen webs para responder, la pregunta ya no es si un resultado se ve más bonito. Es si una máquina que no te leerá entero puede extraer sin equivocarse quién eres, qué vendes y qué respondes.
Aquí el SEO técnico y la visibilidad en motores de inteligencia artificial se tocan: las dos piden lo mismo, que la página diga de forma explícita y coherente lo que un lector humano entiende implícitamente. Cuando este es el objetivo principal, el trabajo tiene página propia en el agencia GEO.
Nada de esto sustituye lo que hay debajo. Una página perfectamente marcada que el buscador no puede renderizar sigue siendo una página que el buscador no tiene. El orden importa, y el marcado va el último.
Cómo se prioriza
No todos los errores técnicos pesan igual, y el orden es la mitad del valor
Cuando un informe detecta cuarenta problemas, la pregunta no es cuáles son: es por dónde empiezas el lunes. El criterio se escribe antes de mirar ninguna web, para que no se pueda acomodar al hallazgo.
Se arregla primero, aunque sea incómodo. Páginas que venden fuera del índice, una regla noindex por accidente, una etiqueta canonical que envía una página importante hacia otra o un bloqueo que impide renderizar. Cada semana que pasa cuesta dinero, y si hace falta se llama antes de acabar el informe.
No te tumba, pero te frena. Duplicados, consultas repartidas entre páginas tuyas, conexiones de idioma rotas, cadenas de redirecciones, arquitectura que deja lo que vende a cinco clics. Se notan como un techo: la web funciona y no sube.
Suma cuando la base ya está limpia. Rendimiento fino, ampliación de datos estructurados, refinamiento de enlaces internos. Hacerlo antes que los dos niveles anteriores es el motivo más frecuente por el que una web bien trabajada sigue sin crecer.
Se mira con datos, no con opinión. Cambios que necesitan tiempo antes de poder juzgarse: reindexación después de una corrección masiva, evolución de impresiones y posiciones, comportamiento de una sección después de una migración.
Qué hay dentro del informe
- La lista priorizada, con los cuatro niveles y el motivo de cada clasificación.
- La prueba de cada punto: dirección, captura o respuesta del servidor, y qué dice Search Console.
- El cambio concreto, escrito para que lo pueda aplicar quien mantiene la web.
- La foto de antes, para que dentro de unos meses se pueda comparar con algo.
- Las fechas de revisión de los puntos que solo se pueden evaluar con el tiempo.
Qué no encontrarás
- Ninguna garantía de posiciones, tráfico ni plazos. Nadie las puede dar, y quien las da te está contando otra cosa.
- Ninguna lista de cuatrocientos avisos exportada de una herramienta y entregada tal cual.
- Ningún punto sin prueba. Si no se puede enseñar por qué es un problema, no entra en el informe.
- Ninguna recomendación que nadie pueda ejecutar porque no dice dónde ni cómo.
Si lo que necesitas es la revisión completa de todo el SEO —técnico, contenido, autoridad y negocio— y no solo la capa técnica, el formato que te toca es la auditoría SEO.
Cómo se sabe si ha servido
Una corrección técnica que no se vuelve a mirar no es una corrección: es una intención
La parte que más a menudo falta no es encontrar el problema ni ejecutarlo: es volver. Se cambia una etiqueta, se limpia un mapa del sitio, y nadie comprueba si el buscador se ha enterado.
Por eso cada punto sale con dos cosas: una foto de antes —cuántas direcciones había en cada estado, qué impresiones y qué posición media tenían las páginas afectadas— y una fecha para volver, fijada al autorizar el cambio y no después. Sin línea base no se puede demostrar ninguna mejora.
Un detalle de calendario: Search Console publica los datos con dos o tres días de retraso. Cerrar un periodo el mismo día que acaba da siempre una caída final que no es real. Es cómo funciona la fuente.
Lo que se mira después de un cambio técnico
Que el estado de las direcciones afectadas se haya movido en Search Console; que el rastreo vuelva a visitarlas; cómo evolucionan las impresiones y la posición de esas páginas; y que no se haya roto nada en otra parte, el riesgo real de toda corrección masiva.
Lo que no se usa como prueba
La nota de una herramienta de laboratorio, los errores desaparecidos de una hoja de cálculo o una subida general de tráfico que podría venir de cualquier otra cosa. Una corrección se demuestra en las páginas que ha tocado, no en el total.
De dónde salen los datos
De cuentas que son del cliente: la web, Analytics, Search Console y la ficha de Google quedan a su nombre y la agencia entra con usuarios propios. Cuando la medición no es fiable, el trabajo previo es el de analítica web.
Orden de trabajo
Del acceso a las cuentas a la validación del cambio
Siempre en este orden: lo que cambia entre un proyecto y otro es lo que se encuentra, no la manera de buscarlo.
Acceso y contexto de negocio
Search Console, analítica, gestor de contenidos y, sobre todo, una conversación sobre qué vende la empresa. Los mismos datos pueden apuntar a dos conclusiones opuestas según si una sección es estratégica o residual, y eso no se deduce de ninguna herramienta: se pregunta.
Rastreo propio y contraste con lo que dice Google
Se rastrea la web entera, se piden las páginas como las pediría un robot y se compara con el estado que Search Console da a cada dirección. Los hallazgos salen de las contradicciones: direcciones que el rastreador encuentra y el buscador no, páginas que el buscador tiene y el rastreador no ve.
Informe priorizado y conversación sobre el orden
Crítico, importante, mejora y seguimiento, con la prueba de cada punto y el cambio concreto. El informe se repasa juntos: el orden final no lo decide solo el impacto de búsqueda, también pesa quién puede ejecutar cada cosa y cuándo. Si aparece algo grave, se dice en ese momento.
Corrección, con copia previa y marcha atrás
La ejecución la puede hacer Daimatics o el equipo técnico que ya tenéis. En los dos casos, cualquier cambio sobre una web publicada se hace con copia de seguridad previa y con un camino de vuelta definido antes de tocar nada.
Validación en la fecha fijada
Se vuelve a mirar lo que se ha tocado, se compara con la foto de antes y se escribe el resultado, haya ido bien o no. Un cambio que no se ha notado también es información: significa que el cuello de botella era otro.
Quién lo mira
Las herramientas encuentran cosas. Decidir cuál importa sigue siendo trabajo de alguien
Daimatics es una agencia fundada por David Nogués, con más de 20 años de trayectoria profesional en el ámbito digital. Es trayectoria de la persona: la marca Daimatics Agency es de abril de 2021.
En una revisión técnica, la parte que no se puede delegar a ninguna herramienta es decidir qué se arregla primero y qué puede esperar seis meses, y eso depende tanto de cómo funciona un buscador como de cómo gana dinero esa empresa. Por eso la primera conversación suele conducirla él mismo, y los proyectos de mayor dimensión, complejidad o importancia estratégica puede llevarlos directamente. La atención se hace en remoto, en castellano y en catalán, de lunes a viernes de 8:00 a 15:00.
- Más de 20 años de trayectoria digitalAtribuida a David Nogués, no a la antigüedad de la empresa.
- Google PartnerAcreditación de la vertiente publicitaria de Google, no un sello de SEO. El propio Google recomienda desconfiar de las herramientas que se presentan como «aprobadas» por Google Search: no avala ninguna.
- Sin permanenciaNada que ate: para dejarlo basta con avisar unos quince días antes. Del precio y de las condiciones se habla en la reunión.
David Nogués, fundador de Daimatics. Comparar lo que sirve la web con lo que acaba recibiendo el buscador es el primer trabajo de cualquier revisión técnica, y el que ninguna herramienta hace sola.
Encaje
Cuándo mirar la base técnica es urgente y cuándo no es lo primero que tienes que hacer
Decir también para quién no es ahorra tiempo a todos: hay momentos en que este trabajo cambia el rumbo de un proyecto y momentos en que sería gastar dinero en la capa equivocada.
Tiene sentido ahora si...
- Publicáis contenido de manera constante y las impresiones no se mueven.
- Ha habido una migración, un cambio de plataforma o una reestructuración de direcciones en los últimos meses.
- Search Console muestra cada vez más páginas rastreadas o descubiertas sin indexar.
- La web tiene dos versiones de idioma y sospecháis que compiten entre ellas.
- Tenéis un catálogo con filtros y no sabéis cuántas direcciones estáis generando de verdad.
- Queréis invertir más en contenido o campañas y preferís saber antes si la base aguanta.
Probablemente no es lo primero si...
- La web tiene pocas páginas, está indexada entera y lo que falta es contenido.
- El problema real es que nadie te conoce: entonces la palanca es autoridad y marca, no rastreo.
- Estáis a punto de rehacer la web desde cero: vale más revisar la nueva arquitectura que la que desaparecerá.
- La medición no es fiable y no sabéis qué páginas convierten: primero la analítica.
- Buscáis clientes en vuestra ciudad y lo que os falta es presencia local: eso se trabaja desde el SEO local.
Preguntas frecuentes
Preguntas que se hacen antes de tocar nada
Las que llegan más a menudo, respondiendo primero y sin dar rodeos.
Concepto¿Qué es el SEO técnico y en qué se diferencia del resto del SEO?
El SEO técnico se ocupa de que un buscador pueda entrar en la web, recibirla entera, entenderla y guardarla. El resto del SEO decide de qué habla la web, la escribe y le consigue autoridad. La diferencia práctica es el orden: si el buscador no puede rastrear o indexar una página, lo que escribas ahí no se puede evaluar. Por eso la revisión técnica suele ir primero, aunque no sea la parte que más se ve.
Utilidad¿Para qué sirve revisar el SEO técnico si la web ya funciona y vende?
Sirve para saber cuánto estás dejando de vender sin verlo. Una web puede facturar bien y al mismo tiempo tener media sección fuera del índice, dos páginas compitiendo por la misma búsqueda o una plantilla que sirve al buscador una versión incompleta. Nada de esto hace saltar ninguna alarma: simplemente no pasa. La revisión convierte ese coste invisible en una lista concreta, con la prueba de cada punto. Si no hay nada grave, también se te dice.
PrioridadesCon decenas de errores técnicos detectados, ¿por dónde hay que empezar?
Por todo lo que impide que una página que vende llegue al índice: reglas noindex puestas por accidente, etiquetas canonicals que envían una página importante hacia otra, bloqueos que impiden renderizar y mapas del sitio que contradicen la web. Después vienen los frenos: duplicados, idiomas mal conectados, cadenas de redirecciones y arquitectura. Lo último es el refinamiento. El criterio no es la gravedad teórica del error, sino cuántas páginas afecta y cuánto valen.
Presupuesto¿De qué depende lo que cuesta arreglar el SEO técnico de una web?
De tres cosas: cuántas direcciones tiene la web de verdad, cuántas plataformas y capas intervienen, y si la corrección la puede aplicar el equipo que ya tenéis. Una parte es trabajo de una sola vez, como limpiar redirecciones o cerrar zonas que no deben indexarse; otra es mantenimiento, porque cada plantilla nueva puede volver a abrir el mismo agujero. Por eso no hay una tarifa por web: se habla en la reunión, con las condiciones por escrito antes de empezar.
Decisiones técnicas¿Qué dominio conviene elegir si se quiere posicionar en varios países o idiomas?
Las tres opciones habituales son un dominio por país, subdominios o carpetas dentro del mismo dominio. La que suele salir más a cuenta para una empresa que empieza a internacionalizarse es la de carpetas, porque concentra la autoridad en un solo dominio en lugar de repartirla. Sea cual sea la opción, lo que decide el resultado no es la dirección: es que las versiones estén conectadas de forma recíproca y que cada idioma mantenga sus enlaces internos.
Criterio de elección¿Cómo se puede saber si quien hace SEO tiene criterio técnico de verdad?
Pidiéndole que te enseñe la prueba de un problema concreto de tu web antes de contratar nada. Quien tiene criterio te dirá qué dirección, qué respuesta del servidor y qué dice Search Console; quien no lo tiene te enseñará una nota sobre cien. Dos preguntas más que separan mucho: qué arreglaría primero y por qué, y cómo sabrás dentro de tres meses si ha servido. Si la respuesta incluye una garantía de posiciones, ya tienes la información que buscabas.
SectorMi web es de un sector muy concreto, como el inmobiliario: ¿cambia el SEO técnico?
Los fundamentos son los mismos en todas partes, pero el peso de cada bloque cambia mucho según el sector. En un portal inmobiliario, o en cualquier web con buscador y filtros, la mayor parte del trabajo se va en controlar cuántas direcciones se generan y qué pasa con las fichas cuando un inmueble se vende. En una web de servicios con pocas páginas, el grueso suele ser cómo se monta la página y el enlazado interno.
Alcance del cambio¿Hay que cambiar de gestor de contenidos o rehacer la web para arreglar los problemas técnicos?
Casi nunca. La mayor parte de los problemas técnicos se corrigen sin tocar el diseño ni cambiar de tecnología: son reglas, etiquetas, redirecciones, configuraciones de plantilla y decisiones sobre qué se indexa. Rehacer la web es una decisión de negocio y, si se toma, vale la pena aprovecharla para resolver la arquitectura de raíz. Lo que no tiene sentido es rehacerla entera por un problema que se resuelve cambiando cómo se genera una etiqueta.
MigracionesDespués de una migración o un cambio de direcciones, ¿qué hay que comprobar para no perder tráfico?
Primero, que cada dirección antigua lleve a la nueva con una redirección permanente hecha en el servidor y en un solo paso, sin cadenas. Segundo, que se mantengan mucho tiempo: Google recomienda conservarlas como mínimo un año, porque es lo que tarda en trasladar las señales. Tercero, que el mapa del sitio ya solo contenga direcciones nuevas. Y cuarto, marcar la fecha del cambio para poder volver meses después.
Lectura de datosGoogle dice «Descubierta: actualmente sin indexar». ¿Qué significa y qué se puede hacer?
Significa que Google sabe que la página existe pero todavía no ha entrado. Según su documentación, el motivo habitual es que quería rastrearla y calculó que hacerlo habría sobrecargado el sitio, así que lo aplazó. Cuando afecta a pocas direcciones no es preocupante; cuando afecta a muchas, suele apuntar a un servidor lento o a una web que genera demasiadas direcciones. Volver a enviarlas a rastrear no sirve de nada.
Primer paso
Los fundamentos técnicos deciden si el resto funciona
Si publicas contenido, inviertes en campañas o quieres rehacer la arquitectura de la web, vale la pena saber antes qué está frenando lo que ya tienes.
