SEO técnico para quien no es programador: lo esencial

El SEO técnico es el conjunto de configuraciones que permite a Google acceder, cargar y entender las páginas de tu sitio: robots.txt, sitemap, canonical, noindex, HTTPS, versión móvil y renderizado de JavaScript. No necesitas programar para dominar lo esencial. Necesitas saber qué comprobar, qué errores salen caros y qué pedirle al desarrollador, con las palabras correctas.

Esta guía forma parte de la guía completa de SEO y parte de lo que viste en cómo Google rastrea, indexa y posiciona: si una de las etapas falla, el mejor contenido del mundo no aparece.

Resumen rápido

• El SEO técnico se ocupa de la elegibilidad: la página debe poder rastrearse, indexarse y mostrarse correctamente.
• El robots.txt controla lo que Googlebot puede rastrear, pero no es una forma de ocultar páginas de la Búsqueda. Para eso existe noindex.
• El sitemap ayuda a Google a descubrir URL, sin garantizar que se rastreen ni se indexen.
• El canonical indica qué versión de una página repetida prefieres. Es una señal, no una orden.
• Google usa la versión móvil del contenido para indexar y posicionar, y prefiere HTTPS.
• El error técnico más caro suele ser sencillo: un bloqueo olvidado después de un lanzamiento.

Cómo leer esta guía: si eres principiante, lee la tabla resumen, el ejemplo hipotético y la lista de lo que hay que pedirle al desarrollador. Si ya trabajas en SEO, ve a los bloques "Para quien ya trabaja en SEO" y a las interacciones entre robots.txt, noindex y canonical.

¿Qué es el SEO técnico y por qué va primero?

El SEO técnico es la parte del SEO que garantiza la "infraestructura" para que todo lo demás funcione. Va primero porque los fallos técnicos anulan el trabajo de contenido: una página bloqueada, con noindex o que no carga para el robot simplemente no entra en el índice.

En lenguaje sencillo: piensa en una tienda. El SEO técnico es la puerta sin llave (robots.txt), el plano del centro comercial actualizado (sitemap), el cartel que dice "la tienda oficial es esta, no la sucursal parecida" (canonical), el aviso de "cerrado al público" (noindex) y el piso que aguanta el peso de quienes entran (servidor, HTTPS, velocidad). El cliente ni nota cuando todo está bien, pero se rinde ante la primera puerta cerrada.

Los requisitos técnicos mínimos forman parte de Google Search Essentials, y la propia documentación recuerda que cumplirlos no garantiza que Google rastree, indexe o muestre la página.

¿Qué hace cada elemento? Visión general

La tabla resume lo esencial, cómo comprobarlo sin programar y qué pedirle al desarrollador.

Elemento	Para qué sirve	Cómo comprobarlo sin programar	Qué pedirle al dev
robots.txt	Le dice a Googlebot dónde no debe rastrear	Abre tudominio.com/robots.txt en el navegador	"Confirma que el robots.txt de producción no bloquea páginas importantes"
Sitemap	Enumera las URL que quieres que Google conozca	Abre /sitemap.xml y mira el informe de Sitemaps en Search Console	"Genera el sitemap solo con URL 200 e indexables, y actualízalo cuando publiquemos"
Canonical	Indica la versión preferida de páginas repetidas	Inspección de URLs: compara la canónica declarada y la seleccionada	"Cada página debe tener un canonical absoluto, que apunte a sí misma o a la versión preferida"
Noindex	Impide que la página aparezca en la Búsqueda	Inspección de URLs: "¿Indexación permitida?"	"Quita el noindex de estas URL" (o aplícalo a las que deban salir)
HTTPS	Conexión segura	Candado en el navegador, sin avisos	"Redirige todo el HTTP a HTTPS con un 301"
Móvil	Google indexa la versión móvil	Abre la página en el celular y compara el contenido	"El contenido y las etiquetas de la versión móvil deben ser iguales a los de la de escritorio"
Renderizado	Garantiza que Google vea el contenido	"Probar URL publicada" en la Inspección de URLs	"El texto principal y los enlaces deben estar en el HTML que entrega el servidor"

¿Para qué sirve el robots.txt y qué no hace?

El robots.txt es un archivo en la raíz del sitio que le dice a los rastreadores a qué URL pueden acceder. Sirve para controlar el tráfico de robots en el servidor. La documentación de Google es directa: no es un mecanismo para mantener una página fuera de Google.

El motivo: una URL bloqueada en el robots.txt aún puede indexarse, solo que sin descripción, si otros sitios la enlazan. Para quitar una página de los resultados, usa noindex o protección con contraseña.

Ejemplo sencillo:

User-agent: *
Disallow: /buscar/
Disallow: /carrito/

Sitemap: https://www.ejemplo.com/sitemap.xml

Lectura: todos los robots pueden rastrear el sitio, excepto /buscar/ y /carrito/. Cuidado con la línea que lo tumba todo: Disallow: / bloquea el sitio entero.

Para quien ya trabaja en SEO: según las especificaciones de Google, los detalles que más sorprenden: el archivo debe estar en la raíz del host (cada subdominio tiene el suyo), en UTF-8, con reglas que distinguen mayúsculas de minúsculas; el límite es de 500 KiB, y lo que pase de eso se ignora; Google guarda el archivo en caché hasta 24 horas. Si la respuesta es 4xx (excepto 429), Google asume que no hay restricciones. Si es 5xx, Googlebot interrumpe el rastreo hasta 12 horas, usa la última versión en caché hasta 30 días y, después de eso, actúa como si no hubiera robots.txt (en sitios generalmente disponibles). Mira más en robots.txt y crawlers de IA.

¿Qué es un sitemap y cuándo lo necesito?

Un sitemap es un archivo que enumera las páginas que quieres que los buscadores conozcan. Ayuda al descubrimiento, pero no garantiza que las URL listadas se rastreen o se indexen. Los sitios pequeños, bien enlazados y sin contenido multimedia enriquecido pueden funcionar sin él, y plataformas como WordPress suelen generar uno automáticamente.

Según la documentación sobre cómo crear sitemaps, un sitemap tiene un límite de 50 MB (sin comprimir) o 50.000 URL, y por encima de eso hay que dividirlo en varios archivos con un índice. Google acepta XML, RSS/Atom y texto sin formato, exige URL absolutas en UTF-8 e ignora las etiquetas <priority> y <changefreq>. La etiqueta <lastmod> solo se usa cuando es consistente y verificablemente precisa, y debe reflejar cambios significativos, no un cambio del pie de página.

Envíalo por el informe de Sitemaps de Search Console o por la línea Sitemap: del robots.txt, incluyendo solo URL que devuelvan 200 y puedan indexarse.

¿Qué es el canonical y cómo evitar páginas repetidas?

El canonical es la indicación de la URL preferida cuando el mismo contenido (o uno muy parecido) existe en más de una dirección. Esto ocurre con más frecuencia de la que parece: http y https, con y sin www, parámetros de filtro, versiones para imprimir.

La documentación sobre URL duplicadas describe los métodos como señales, no como órdenes. Recomienda URL absolutas en rel="canonical", un canonical en la propia página canónica (autorreferente), consistencia en los enlaces internos y ningún conflicto entre métodos. Ejemplo:

<link rel="canonical" href="https://www.ejemplo.com/blog/como-elegir-primera-guitarra" />

Para archivos que no son HTML, como los PDF, el canonical puede enviarse como cabecera HTTP. La duplicidad en sí no se penaliza: el problema es dividir las señales y dejar que Google elija por ti.

Para quien ya trabaja en SEO: la documentación ordena las señales de canonicalización: las redirecciones y rel="canonical" son fuertes, y la inclusión en el sitemap es débil; Google también prefiere HTTPS a HTTP por defecto. Cuando Search Console muestra que la canónica elegida por Google es distinta de la declarada, hay una contradicción entre señales (enlaces internos hacia otra variación, redirecciones, contenido muy parecido). Y, si el canonical se inyecta con JavaScript, Google pide que sea idéntico al del HTML original.

¿Qué es noindex y cuándo usarlo?

Noindex es una instrucción que le pide a Google que no ponga la página en el índice. Úsalo en páginas que no deben aparecer en la Búsqueda, como los resultados de la búsqueda interna del sitio, las páginas de agradecimiento y los entornos de pruebas (lo ideal es protegerlos con contraseña).

Google documenta dos formas, en la página sobre cómo bloquear la indexación:

<meta name="robots" content="noindex">

X-Robots-Tag: noindex

La primera va en el HTML; la cabecera HTTP sirve también para archivos que no son HTML. Dos trampas importantes: la página no puede estar bloqueada en el robots.txt, porque entonces Googlebot nunca ve el noindex; y el efecto no es inmediato, porque puede tardar meses en que Googlebot vuelva a visitar páginas de poca importancia. La Inspección de URLs de Search Console confirma si ya ve la regla.

HTTPS, redirecciones y errores: ¿qué comprobar?

Lo básico es: todo el sitio en HTTPS, las versiones antiguas redirigiendo a la nueva con un 301 y las páginas inexistentes respondiendo 404, no 200. Google enumera HTTPS como parte de la experiencia de página, y el sistema de canonicalización prefiere HTTPS por defecto.

• 301 o 308 (permanentes): le dicen a Google que el destino debe ser la versión canónica. Úsalos en cambios de dominio, de URL o al consolidar páginas.
• 302 o 307 (temporales): no transmiten esa señal, y la URL antigua puede seguir indexada. Úsalos solo si el cambio es temporal.
• Cadenas de redirecciones: evita varios pasos. Los rastreadores siguen hasta 10 saltos, según la documentación de códigos HTTP de Google, pero cada salto retrasa al usuario y al robot.

En lenguaje sencillo: una redirección 301 es el aviso definitivo de cambio de dirección pegado en la puerta de la tienda vieja: "ahora estamos allá". Un 302 es el cartel de "volvemos enseguida", que no hace que nadie cambie la dirección en su agenda.

¿Qué exige Google del sitio móvil?

Google usa la versión móvil del contenido para indexar y posicionar. La documentación sobre indexación mobile-first pide que el sitio móvil tenga el mismo contenido que el de escritorio (poner texto en pestañas o acordeones es aceptable, quitarlo no), las mismas metaetiquetas de robots y los mismos datos estructurados. También avisa de que Google no carga contenido que depende de una interacción, como desplazarse, hacer clic o escribir.

Prueba sencilla: abre tus páginas principales en el celular. Lo que existe solo en la computadora puede quedar fuera de lo que Google indexa.

¿Cómo afecta JavaScript al SEO?

Si tu sitio muestra el contenido solo después de ejecutar JavaScript, Google aún puede verlo, pero en otra etapa y con algo de retraso. Según la guía de SEO para JavaScript, el proceso tiene tres fases (rastreo, renderizado, indexación), y la recomendación es preferir el renderizado en el servidor o el prerenderizado, que también beneficia a usuarios y robots que no ejecutan JavaScript.

La misma guía pide enlaces reales con <a href>, URL de verdad (History API, y no fragmentos #) y códigos HTTP correctos: una página inexistente debe devolver 404, no 200, o se convierte en un "soft 404".

¿Qué pedirle al desarrollador? Lista y modelo de mensaje

Pide por problema y por evidencia, no por tecnología:

1. Confirmar que el robots.txt de producción no tiene Disallow: / y no bloquea carpetas importantes.
2. Quitar noindex (meta o cabecera) de las páginas que deben aparecer en la Búsqueda.
3. Generar un sitemap con URL 200, canónicas e indexables, y declararlo en el robots.txt.
4. Definir rel="canonical" absoluto y autorreferente en cada página indexable.
5. Redirigir HTTP a HTTPS y www o no www a una única versión, con 301.
6. Asegurar que el contenido y los enlaces principales estén en el HTML que entrega el servidor.
7. Hacer que la versión móvil tenga el mismo contenido y las mismas etiquetas que la de escritorio.
8. Devolver 404 (o 410) para páginas inexistentes, y nunca 200 con un mensaje de error.

Modelo de mensaje: "En Search Console aparece [estado] para [URL], pero la página debería estar indexada. ¿Puedes verificar si hay un meta robots o un X-Robots-Tag con noindex en producción? Captura adjunta. Después vuelvo a inspeccionar la URL."

Ejemplo hipotético: el sitio que desapareció tras el relanzamiento

Ejemplo hipotético: una tienda relanza su sitio en una plataforma nueva. Diez días después, el tráfico de Google cae de forma brusca. El dueño piensa que "Google nos penalizó" y empieza a reescribir textos.

Quien conoce el SEO técnico sigue otra secuencia. Abre /robots.txt y encuentra Disallow: /, una regla heredada del entorno de pruebas. Abre la Inspección de URLs en una página de producto y ve "Bloqueada por robots.txt". Le pide al desarrollador que cambie el archivo por una versión de producción y comprueba que tampoco haya quedado un meta noindex en las plantillas. Reenvía el sitemap e inspecciona las URL principales. Después sigue la indexación durante las semanas siguientes.

Nada de esto exigió código, solo saber dónde mirar. La guía de Google Search Console para principiantes muestra cómo leer esos informes.

Preguntas frecuentes

¿Qué es el SEO técnico?

Es el conjunto de ajustes que garantiza que Google pueda rastrear, indexar y mostrar las páginas del sitio: robots.txt, sitemap, canonical, noindex, HTTPS, versión móvil, renderizado de JavaScript y velocidad. No mejora el contenido en sí, pero sin él el contenido puede no verse nunca.

¿Cuál es la diferencia entre robots.txt y noindex?

El robots.txt controla lo que Googlebot puede rastrear. El noindex pide que la página no se indexe. Para ocultar una página de los resultados, usa noindex y no bloquees la página en el robots.txt, porque Googlebot necesita acceder a ella para leer la instrucción. Una URL bloqueada aún puede aparecer sin descripción.

¿Todo sitio necesita un sitemap?

No necesariamente. Google dice que los sitios pequeños, bien enlazados internamente y sin contenido multimedia enriquecido pueden prescindir de él. Para sitios grandes, nuevos, con pocos enlaces externos o con muchos vídeos e imágenes, el sitemap ayuda al descubrimiento. En cualquier caso, no garantiza la indexación.

¿El canonical es obligatorio?

No, pero se recomienda. Sin él, Google elige por su cuenta la versión principal entre páginas parecidas, usando sus propias señales. Declarar un canonical absoluto y autorreferente reduce el riesgo de que elija una variación que no quieres, aunque el canonical sea una señal y no una orden.

¿Cómo saber si Google ve mi página correctamente?

Usa la Inspección de URLs de Search Console y ejecuta la prueba en vivo: muestra si la página se puede rastrear, si hay un bloqueo por robots.txt o noindex, qué canónica eligió Google y cómo se renderizó la página. La versión indexada puede ser distinta de la actual, porque refleja la última visita.

Siguiente paso

Con la base técnica revisada, el siguiente paso es repasar todo el sitio de una vez: la guía de auditoría SEO paso a paso reúne estas comprobaciones en una ruta completa. Para entender las métricas de velocidad y estabilidad, lee Core Web Vitals explicado.

Lee también:

• Robots.txt y crawlers de IA
• Google Search Console: guía para principiantes
• SEO on-page: checklist completo para cada página