SEO técnico para desarrolladores
Las ocho cosas que decides al escribir código y que determinan si Google puede indexar tu sitio. Sin marketing: rastreo, canonical, datos estructurados y qué se rompe en silencio.
El SEO técnico es la parte del posicionamiento que se decide escribiendo código, no escribiendo textos: si un buscador puede llegar a tus páginas, entenderlas y saber cuál es la versión buena de cada una. No sustituye a tener contenido que valga la pena, pero sin él, el contenido bueno no llega a competir.
La mala noticia es que casi todo lo que se rompe aquí se rompe en silencio. Ninguna prueba falla, el sitio carga perfecto y las páginas simplemente dejan de existir para Google. Estas son las ocho cosas que conviene tener resueltas, en el orden en que importan.
1. Que se pueda rastrear
Antes que nada: ¿puede un rastreador ver tu contenido? Tres formas habituales de que la respuesta sea no:
- Un
robots.txtque bloquea de más. UnDisallow: /heredado del entorno de pruebas es el clásico. - Contenido que solo existe después de ejecutar JavaScript. Google renderiza, pero en una segunda pasada que puede tardar, y otros rastreadores directamente no lo hacen.
- Enlaces que no son enlaces. Un
<div onclick>o un botón que navega con JavaScript no es un camino que nadie pueda seguir. Un enlace es<a href>, sin excepciones.
Comprobación rápida: pide la página con curl y busca tu contenido en la respuesta. Si no está en el HTML, estás apostando a que el rastreador lo renderice.
2. Que se pueda indexar
Rastrear e indexar no son lo mismo. Una página se puede leer perfectamente y aun así quedarse fuera del índice porque lleva <meta name="robots" content="noindex">.
Ese noindex es una herramienta, no un error: lo quieres en el acceso, el registro, las páginas de resultados internos y cualquier cosa detrás de una cuenta. Lo que no quieres es que se cuele en una plantilla compartida. Es un fallo de una línea que se lleva por delante una sección entera.
3. El canonical, sobre todo si tienes parámetros
El canonical le dice a Google cuál es la URL buena cuando hay varias que enseñan lo mismo. La necesitas en cuanto tengas parámetros de consulta, barra final opcional, o mayúsculas y minúsculas mezcladas.
Dos reglas que evitan el 90 % de los problemas:
- El canonical de cada página apunta a sí misma salvo que de verdad sea una copia.
- Elige una forma y quédate con ella: con barra final o sin ella, pero no las dos. Y que el sitemap use exactamente la misma.
El error caro es el canonical que apunta siempre a otra página. Nosotros lo tuvimos con los idiomas: la versión inglesa declaraba como canónica la española, que es decirle a Google «ignora esto, es un duplicado». Lo contamos en hreflang para un sitio en dos idiomas.
4. El sitemap tiene que ser la lista completa
Un sitemap no mejora el posicionamiento; sirve para que se descubra lo que existe. El problema aparece cuando se queda viejo sin que nadie se entere, que es lo normal si se escribe a mano.
En sitios renderizados en el servidor esto es más grave de lo que parece: los generadores de sitemap suelen descubrir solo lo que se construye estáticamente, y si todas tus rutas son dinámicas, no descubren ninguna. Nos pasó exactamente eso: dos páginas pasaron a renderizarse en el servidor y desaparecieron del sitemap sin romper nada. El detalle, en sitemap.xml y robots.txt: cómo configurarlos.
5. Títulos y descripciones, con sus límites reales
Cada página necesita un <title> y una <meta name="description"> propios. Los rangos que aguantan sin que Google los reescriba:
| Elemento | Longitud útil | Qué pasa fuera de rango |
|---|---|---|
title |
15–60 caracteres | Se corta con puntos suspensivos |
description |
70–160 caracteres | Por debajo, Google la ignora y escribe la suya |
h1 |
Uno por página | Con varios, ninguno destaca |
Y ojo con el sufijo: si añades · Mi sitio a todos los títulos, esos caracteres cuentan. Un título de 55 más un sufijo de 10 son 65, y se corta.
6. Datos estructurados, pero solo los que puedes sostener
El JSON-LD es lo que convierte un resultado normal en uno con estrellas, precios o preguntas desplegables. También es la forma más fácil de prometer algo que no está en la página, y eso sí tiene consecuencias.
Regla única: marca solo lo que el usuario ve. Si el schema dice que hay diez preguntas frecuentes, tiene que haber diez preguntas frecuentes visibles. Lo desarrollamos en datos estructurados: qué marcar y qué no.
7. Rendimiento, en el orden que importa
Las métricas de experiencia de usuario influyen, aunque menos de lo que dice el sector. Vale la pena por los usuarios antes que por Google, y hay un orden claro de retorno:
- Reserva el espacio de las imágenes con
widthyheight. Evita que el contenido salte y cuesta cinco minutos. - No bloquees el renderizado con CSS y fuentes innecesarias. Un
font-display: swapes casi gratis. - Sirve imágenes del tamaño en que se ven. Es donde está casi todo el peso de una página normal.
- Lo demás, cuando lo anterior esté hecho.
8. Que se pueda comprobar solo
Este es el que casi nadie monta y el que evita todos los demás. El SEO técnico se pudre en silencio: nada falla, nada avisa, y te enteras meses después mirando una gráfica que baja.
La solución no es una auditoría anual, es un script que rastree tu propio sitio y falle con código de salida distinto de cero. Que compruebe: que el sitemap existe y cubre lo público, que ninguna página pública lleva noindex, que todas tienen canonical y h1, que los títulos están en rango y que no hay enlaces internos rotos.
Nosotros tenemos uno y encontró cosas que llevaban semanas rotas sin que nadie lo notara. Es la pieza con mejor relación entre esfuerzo y daño evitado de toda esta lista.
Por dónde empezar hoy
Si solo vas a hacer una cosa: pide tres páginas de tu sitio con curl y mira el HTML crudo. Título, descripción, canonical, h1 y que el contenido esté ahí sin ejecutar JavaScript. En quince minutos sabes si tienes un problema de SEO técnico o de contenido, y son problemas muy distintos.
Para medir después, en herramientas SEO gratis para tu proyecto están las opciones con plan gratuito de verdad.
Preguntas frecuentes
¿Cuánto tarda Google en indexar una página nueva? Va de horas a semanas, y depende sobre todo de la frecuencia con que rastree tu sitio, que a su vez depende de cuánto publiques y de cuántos enlaces recibas. Un sitio nuevo sin enlaces externos puede tardar semanas; uno que publica cada semana suele ver las páginas nuevas en días.
¿Necesito renderizado en el servidor para posicionar? No es obligatorio: Google ejecuta JavaScript. Pero lo hace en una segunda pasada, con retraso, y otros rastreadores —incluidos varios asistentes de IA— no lo hacen en absoluto. Si el contenido importa, que esté en el HTML de la primera respuesta.
¿Los datos estructurados suben posiciones? Directamente no. Lo que hacen es cambiar el aspecto del resultado, y un resultado con preguntas desplegables o valoraciones se lleva más clics con la misma posición. La mejora es de tasa de clics, no de ranking.
¿Qué hago con las páginas paginadas? Que cada una tenga su propio canonical apuntando a sí misma y un título que la distinga. Lo que no debes hacer es poner el canonical de todas hacia la página 1: eso le dice a Google que ignore el contenido de las demás.
¿Merece la pena comprar enlaces? No, y además es exactamente el tipo de cosa que Google detecta y penaliza. Un enlace vale por el tráfico real que trae y por el contexto en el que aparece; un enlace comprado no tiene ninguna de las dos cosas.
El directorio es la otra mitad de esto
115 servicios con plan gratuito real, con los límites de cada uno escritos en claro. Sin registro para empezar a mirar.