Por qué me interesa el SEO técnico y no el "SEO mágico"

Gestiono caprini.dev con un frontend propio en Next.js sobre contenido de Ghost, así que el SEO técnico no es opcional para mí: cada decisión de arquitectura afecta directamente a cómo los buscadores pueden leer e indexar el contenido. No voy a hablar aquí de trucos ni de promesas de posicionamiento; el SEO técnico no garantiza tráfico, solo evita que un contenido bueno quede invisible por un problema técnico evitable.

Lo primero: que el contenido sea rastreable

Antes de pensar en metadatos o en datos estructurados, hay que confirmar lo más básico: que un buscador pueda acceder al contenido sin bloqueos innecesarios.

  • Reviso el robots.txt para asegurarme de que no bloquea por error rutas que sí quiero indexadas. Es fácil, al añadir una regla para una sección privada (como el panel de administración de Ghost), bloquear sin querer una ruta pública por un patrón demasiado amplio.
  • Confirmo que las páginas devuelven el código de estado HTTP correcto: un artículo eliminado debería devolver 404, no una página vacía con código 200, porque eso confunde tanto a usuarios como a buscadores.
  • Compruebo que no haya cadenas largas de redirecciones entre la URL antigua de un artículo y su versión final.

Metadatos que sí importan

De toda la lista de metadatos posibles, hay un grupo reducido en el que centro la atención real:

  1. Título único por página, que describa el contenido sin repetir exactamente la misma fórmula en todos los artículos.
  2. Meta descripción específica, pensada para animar al clic desde resultados de búsqueda, no una plantilla genérica copiada en todos los posts.
  3. Etiqueta canonical correcta, especialmente importante en mi caso porque el mismo contenido puede ser accesible desde más de una ruta si no se gestiona bien el enrutado del frontend.
  4. Open Graph básico (título, descripción, imagen) para que los enlaces compartidos en redes o mensajería se vean bien, aunque esto afecte más a la experiencia social que al posicionamiento en sí.

Datos estructurados: útiles, pero no obligatorios para todo

Añadir datos estructurados (schema.org) puede ayudar a que un buscador entienda mejor el tipo de contenido, pero no es necesario forzarlo en todo. En mis artículos de blog uso un marcado básico de tipo artículo, con autor, fecha de publicación y fecha de modificación. No añado marcados más agresivos (como preguntas frecuentes o reseñas) si el contenido real no encaja con ese formato, porque un marcado que no corresponde al contenido visible puede generar más problemas que beneficios.

Rendimiento como factor técnico, no solo de experiencia

El rendimiento de carga afecta tanto a la experiencia de quien lee como a cómo los buscadores evalúan la página. En un blog pequeño, los puntos que más impacto tienen suelen ser:

  • Imágenes sin optimizar, servidas en un tamaño mucho mayor del necesario para el diseño real.
  • Fuentes tipográficas que bloquean el renderizado del texto hasta que terminan de cargar.
  • Scripts de terceros (analíticas, widgets) cargados de forma síncrona cuando podrían cargarse de forma diferida.

Ninguno de estos problemas es exclusivo de blogs pequeños, pero en un proyecto sin equipo dedicado a rendimiento, es fácil que se acumulen sin que nadie los note hasta que se revisan explícitamente.

Con qué frecuencia reviso todo esto

No trato el SEO técnico como una configuración que se hace una vez y se olvida. Cada vez que cambio algo en el frontend del blog, aunque sea un ajuste visual aparentemente inofensivo, reviso de nuevo los puntos básicos: que el robots.txt siga permitiendo el rastreo de lo que debe, que los títulos y descripciones no se hayan roto por un cambio en la plantilla, y que el tiempo de carga no haya empeorado de forma perceptible.

Esta revisión no necesita ser exhaustiva cada vez; basta con una comprobación rápida de los puntos que ya sé que son sensibles a cambios de código, como el enrutado de las páginas de artículo o la generación de metadatos dinámicos.

Indexación: verificar, no asumir

Una lección que aprendí revisando mi propio blog es no asumir que "publicado" significa "indexado" ni siquiera "listado correctamente en el propio sitio". Detecté casos donde un artículo estaba publicado, presente en el sitemap, pero no aparecía en el índice visual de artículos del propio sitio por un problema de filtrado en el frontend. Profundizo en este caso concreto en por qué un sitemap puede ser más importante que publicar veinte artículos.

La lección general es: revisar periódicamente que lo que crees que está publicado y visible, realmente lo esté, en lugar de confiar en que el sistema lo hace todo bien por defecto.

Lo que el SEO técnico no puede arreglar

Quiero cerrar con un límite importante: ningún ajuste técnico compensa contenido débil o irrelevante para quien lo busca. El SEO técnico elimina obstáculos, pero no crea valor donde no lo hay. Por eso lo trato como una condición necesaria, no suficiente, y lo combino con criterios de contenido que desarrollo en cómo planteo los enlaces internos en un blog técnico y en cómo evito el contenido de relleno.

Referencia oficial: Guía de introducción a SEO de Google Search Central.

Conclusión

El SEO técnico de un blog pequeño no requiere herramientas complejas ni un equipo dedicado; requiere revisar con regularidad un conjunto reducido de aspectos concretos: rastreo, metadatos, rendimiento e indexación real. Lo que sí exige es no dar por hecho que, una vez configurado, todo sigue funcionando igual con el tiempo.