Buenas prácticas SEO en Desarrollo Web

En lo que va de año, a las puertas de 2026, llevo hechas 4 auditorías SEO y varias sesiones de Mentoría SEO para agencias de marketing digital con las que he podido analizar un gran número de sites y sigo encontrándome con incidencias o incluso errores graves de desarrollo web que acaban impactando negativamente en el SEO de éstos proyectos.

Por poner algún ejemplo grave de lo analizado recientemente, he visto webs en las que desde el menú de navegación se enlazaban a decenas de URLs noindex y/o canonicalizadas, verticales enteros en algunos casos, que además debían atacar intenciones de búsqueda de negocio. Y sí, he puesto «webs» en plural.

No os llevéis las manos a la cabeza, esto sigue pasando porque, en realidad, un desarrollador web no tiene por qué saber SEO para hacer una web (Hola KIT Digital!) pero es 100% recomendable que tenga unos conocimientos mínimos porque NO VEAS LO QUE SUMA cuando saben o por lo menos quieren saber.

Ahora me encuentro justo al inicio de un proyecto en el que la empresa que va a ser responsable del desarrollo de una nueva web, en la que me consta que su equipo tiene conocimientos de SEO, me ha pedido que le haga llegar una serie de buenas prácticas SEO o consejos SEO para empezar con buen bien pie y reducir al mínimo posibles correcciones o modificaciones futuras.

Me asaltó la duda de aglutinar diferentes contenidos de la base de conocimiento que tengo en Obsidian en un documento unificado, ampliarlo un poco y enviárselo o bien hacer un post y publicarlo aprovechando para darle algo de vidilla al blog y bueno… aquí estoy.

Disclaimer: Ningún desarrollador web ha sufrido daños durante la redacción de este artículo.

1. Accesibilidad y Rastreo (SEO 101)

Antes de que el contenido posicione, Googlebot debe poder acceder a él para poder incluirlo en su índice. Estas son unas buenas prácticas para facilitar rastreo e indexación de URLs relevantes.

1.1 Archivo Robots.txt

El archivo robots.txt en la raíz del dominio controla por dónde pasan los bots de buscadores. Para bots de inteligencia artificial como ChatGPT ha surgido la iniciativa del LLMS.txt que no incluiré en este artículo ya que por lo menos hasta hace unos meses Google indicó a través de John Mueller en Bluesky que no usaba lo que se indica en este documento.

• Entornos de Desarrollo/Staging: Deben bloquear todo el rastreo para evitar indexar contenido de prueba.
  • User-agent: *
  • Disallow: /
• Entorno de Producción: Debe permitir el acceso a todo el contenido público y recursos de carga (CSS, JS, Imágenes). Nunca bloquear carpetas de estilos o scripts. Imprescindible: Revisar el robots.txt cuando se pasa de de pre-producción/staging a producción. Un clásico.
• Sitemap.xml : Incluir en el robots.txt la URL en la que se puede encontrar el sitemap.xml
  • Sitemap: https://www.dominio.com/sitemap.xml

1.2 Sitemap.xml

• Debe generarse dinámicamente.
• Solo debe incluir URLs que devuelvan un código de estado 200 OK, canónicas e indexables.
• Excluir: URLs con redirecciones (301), errores (404), páginas protegidas por contraseña, páginas que se vayan a usar para campañas o páginas de «gracias» post-conversión. Estas 2 últimas deben ser «noindex,follow».

1.3 Códigos de Estado HTTP

El servidor debe responder con precisión:

• 200 OK: La página carga correctamente. Si se trata de un sitio web nuevo no deberíamos contar con URLs que no tuviesen otro código de respuesta que este 200.
• 301 Moved Permanently: Para redirecciones definitivas y traspaso de autoridad SEO.
• 302 Found: Redirección temporal. Evitar su uso salvo casos muy específicos.
• 404 Not Found: Cuando el contenido ya no existe.
  • ⚠️ Evitar «Soft 404»: No mostrar una página de error visual mientras el servidor devuelve un código 200. Si es error, el header debe ser 404 y ningún otro.

2. Arquitectura y Sintaxis de URLs

La URL es la dirección de nuestro contenido y debe seguir reglas estrictas de formato. La casuística en este punto puede ser muy diversa y conviene aplicar estas recomendaciones SEO para evitar incidencias.

2.1 Uso de Minúsculas (Casing)

Las URLs para los buscadores como Google son case-sensitive, esto significa que para ellos la URL /Servicios es una URL distinta de /servicios . Para evitar estas incidencias:

• Regla: Todas las URLs deben forzarse a minúsculas (lowercase).
• Implementación: Si un usuario escribe /Contacto, el servidor debe redirigir (301) a /contacto. En el caso de que el CMS impida gestionar esto de forma eficiente confirmar que la variación de URL con mayúsculas está correctamente canonicalizada a la versión en minúsculas y que no existen enlaces internos a ellas.

2.2 Separadores

• Usar siempre guiones medios (-) para separar palabras.
• ❌ Nunca usar guiones bajos (_) ni espacios (%20).
  • Bien: mi-web.com/servicios-empresariales
  • Mal: mi-web.com/servicios_empresariales

2.3 Legibilidad o URLs amigables (Slugs)

Evitar parámetros ininteligibles siempre que sea posible. Las URLs deben ser semánticas.

• ❌ Mal: /producto.php?id=583
• ✅ Bien: /zapatillas-deportivas-rojas

2.4 Barra Final (Trailing Slash)

Debemos definir una única convención para todo el sitio: o todas las URLs terminan en barra (/) o ninguna.

• Si se accede a la versión contraria, debe haber una redirección 301 automática hacia la versión canónica elegida para evitar duplicidades.

2.5 HTTPS y www/no-www

Hay que mantener todo el site con navegación segura y con coherencia en sus URLs, bien con www o sin www pero no ambas.

• Cualquier petición a una URL con http debe hacer un 301 hacia su equivalente con HTTPS
• Si usamos «www.» cualquier petición a una URL sin «www.» debe hacer un 301 hacia esa URL con «www.». Si no usamos «www.» pues a la inversa.

3. Estructura Semántica y Contenidos (HTML)

Google lee el DOM para entender la jerarquía y relevancia del contenido.

3.1 Etiquetas de Encabezado (Headings)

• H1: Obligatorio y único por URL. Describe el tema principal de la página. Incluye en este la keyword principal asociada a la intención de búsqueda de la página.
• H2 – H6: Deben seguir un orden lógico jerárquico. No usar un H4 después de un H2 solo por el tamaño de la letra (eso se gestiona con CSS/Clases). ⚠️Insisto: NO USAR HEADINGS para maquetar, usarlos para estructurar.

3.2 Etiquetas Meta (Editables)

Si bien la redacción no corresponde al equipo de desarrollo si es recomendable que conozcan la relevancia de title y description. Cada página debe permitir editar desde el CMS o configuración:

• Title Tag: <title>. El factor más importante «on-page». Único por URL.
• Meta Description: <meta name="description">. Resumen para el usuario en los resultados de búsqueda.

3.3 Etiqueta Canonical (Anti-Duplicidad)

Fundamental para evitar liar a los buscadores:

• Cada página debe tener un <link rel="canonical" href="URL_ACTUAL_ABSOLUTA" /> en el <head>.
• Esto le dice a Google: «Esta es la versión original y preferida de esta página».

3.4 Webs 100% responsive

Las Webs 100% responsive conviven con nosotros desde hace más de 10 años, no es necesario duplicar contenidos y gestionar su visibilidad con display:none; según sean para Desktop o Mobile.

Tampoco debemos usar display:none; para ocultar contenido que en realidad no debería estar en código, si por ejemplo un enlace no debería aparecer en la página se debe eliminar de código, no ocultarlo con este atributo de CSS. ¡¡Fin a esto por favor!!.

4. Gestión de Enlaces (Enlazado Interno)

Cómo conectamos las páginas entre sí afecta al rastreo y a su posicionamiento, hacerlo de una forma eficiente no solo nos va a ayudar en esto si no que también mejorará la experiencia de usuario.

4.1 Enlaces de Navegación

• Siempre usar etiquetas <a> con atributo href.
• ❌ Evitar: Elementos <div>, <span> o <button> con eventos onclick de JavaScript para navegar. Googlebot no siempre ejecuta esos eventos y podemos dificultar el rastreo en URLs importantes.

4.2 Atributos de Enlace

• Enlaces Internos: Sin atributos especiales (follow por defecto).
• Enlaces Externos: Si enlazamos a sitios de terceros (especialmente si son patrocinados o contenido generado por usuario), usar rel="nofollow", rel=»sponsored» o rel="ugc" según el caso.

4.3 Anchoring de enlaces

En la medida de lo posible contextualiza los elementos clicables del enlace, es decir el texto sobre el que se hace clic. Enlaces de tipo CTAs, lectura de artículos, etc es mejor que describan qué se va a encontrar en la URL de destino, es mejor un «Consultoría SEO» que «Ver sección».

5. Imágenes y Multimedia

La optimización de medios es crítica para la velocidad y la búsqueda visual. Las imágenes suelen ser la principal fuente de incidencias de velocidad de carga y es importante tenerlas optimizadas.

5.1 Atributo Alt

Todas las etiquetas <img> deben tener el atributo alt.

• Si es decorativa: alt="" (puede ir vacío).
• Si aporta contenido: alt="Descripción breve de la imagen".

5.2 Dimensiones Explícitas (CLS)

Para evitar que el contenido «salte» o se mueva mientras carga (incidencia de Core Web Vitals «Cumulative Layout Shift»):

• Especificar siempre width y height en el HTML o reservar el espacio mediante CSS aspect-ratio antes de que la imagen cargue.

5.3 Carga Diferida (Lazy Loading)

• Añadir loading="lazy" a todas las imágenes below the fold, es decir, que no estén en la pantalla inicial o above the fold.
• La imagen principal (Hero image) no debe tener lazy loading.

6. Rendimiento y Velocidad (WPO)

La velocidad de carga es un factor directo de posicionamiento en situaciones graves con elevado % de URLs pobres.

• Minificación: Servir archivos CSS y JS minificados en producción.
• Compresión: Habilitar GZIP o Brotli en el servidor.
• Formatos Next-Gen: Priorizar el uso de formatos WebP o AVIF frente a JPG/PNG tradicionales.

7. JavaScript y Renderizado (Para SPA/Frameworks)

Si usamos React, Vue, Angular, etc.:

• Server Side Rendering (SSR): Es altamente recomendable que el servidor entregue el HTML ya renderizado. Si Google recibe una página en blanco que depende totalmente de JS para mostrar texto, la indexación será lenta e inestable.
• Hidratación (hydration): El contenido importante (H1, textos, enlaces) debe estar presente en el código fuente inicial.

Con todos estos puntos creo que cubro un amplio espectro de elementos que forman parte del desarrollo web y que en muchísimas ocasiones me encuentro reportando en auditorías. Mi único objetivo es explicar de forma rápida y breve estas cosas para tratar de evitar incidencias o hábitos históricos que perduran aún hoy.

Espero que te guste, si es así… o no, te leo en comentarios.