Del viewport al componente

El responsive clásico parte del viewport. Definimos breakpoints globales, por ejemplo a 768px o 1024px, y ahí decidimos cómo cambia el layout completo. Ese enfoque sigue funcionando, pero tiene una limitación clara: asume que todos los componentes viven en el mismo contexto.

En proyectos con sidebars, grids asimétricos, módulos reutilizados en varias plantillas o bloques que pasan de una columna ancha a otra estrecha, esa suposición deja de ser fiable. El container no necesita saber cuánto mide la pantalla; necesita saber cuánto espacio recibe.

Media queries responden al entorno global; container queries responden al entorno local del componente.

Qué son las media queries

Las media queries aplican estilos basados en características del dispositivo o del viewport: anchura, altura, orientación o tipo de medio. Son la base del responsive tradicional y siguen siendo la mejor herramienta para decisiones globales.

• Cambiar la estructura principal de la página.
• Reorganizar cabecera, sidebar o footer.
• Adaptar navegación, overlays o patrones dependientes de pantalla.

Qué son las container queries

Las container queries permiten aplicar estilos según el tamaño de un contenedor concreto. En lugar de tomar como referencia el viewport, toman el contenedor, normalmente con container-type: inline-size;.

Eso permite que una misma card, un mismo módulo o una misma pieza de UI se comporte de forma distinta según el ancho real de la columna donde aparece. Es un cambio enorme para design systems y sitios basados en componentes.

Un componente reusable deja de depender de breakpoints globales “prestados” y gana autonomía dentro del layout.

Diferencias clave

Sintaxis comparada

La diferencia conceptual es grande, pero la sintaxis no resulta extraña. Ese parecido hace que la curva de aprendizaje sea relativamente suave si ya trabajas con CSS moderno.

.card {
  display: block;
}

@media (min-width: 768px) {
  .card {
    display: grid;
    grid-template-columns: 220px 1fr;
    gap: 1.5rem;
  }
}

.card-wrapper {
  container-type: inline-size;
}

.card {
  display: block;
}

@container (min-width: 30rem) {
  .card {
    display: grid;
    grid-template-columns: 220px 1fr;
    gap: 1.5rem;
  }
}

Cuándo usar cada una

Usa media queries cuando el cambio sea estructural

• El layout general pasa de una columna a varias.
• La navegación cambia de desktop a móvil.
• Hay decisiones ligadas al viewport completo.

Usa container queries cuando el cambio sea interno al componente

• Cards, grids internos, módulos de contenido o bloques reutilizados.
• Componentes que aparecen en zonas de ancho variable.
• Interfaces donde el mismo módulo vive en contextos muy distintos.

Estrategia recomendada hoy

La combinación más sólida no es elegir una tecnología y descartar la otra. Lo más sensato es usar media queries para el layout macro y container queries para la lógica responsive interna de los componentes.

Una buena regla práctica: si estás diseñando la página, piensa en media queries; si estás diseñando un bloque reusable, piensa primero en container queries. Ese cambio de mentalidad ayuda a escribir CSS más escalable, legible y portable entre plantillas.

Patrón útil: MQ para estructura, CQ para componentes. No compiten; se complementan.

¿Qué es el glassmorphism hoy?

Glassmorphism es un estilo que imita el vidrio esmerilado: superficies semitransparentes, fondos desenfocados y bordes sutiles sobre fondos ricos en color o textura.

La clave no es el blur por sí mismo, sino cómo se combinan transparencia, desenfoque, sombras y capas para crear jerarquía y sensación de profundidad.

En 2026, muchos sistemas lo usan como “capa intermedia”: paneles, overlays y tarjetas que flotan por encima de fondos más expresivos, no como filtro global de toda la interfaz.

De moda pasajera a lenguaje visual estable

Desde 2020, el glassmorphism se consolidó gracias a Apple, Microsoft y herramientas que popularizaron el efecto de “cristal” en interfaces y generadores de CSS.

Hoy, la tendencia se ha refinado en lo que algunos llaman “Glassmorphism 2.0” o incluso “Liquid Glass”: menos ruido decorativo, más foco en claridad, accesibilidad y respuesta al contexto.

No se trata tanto de “poner blur en todas partes”, sino de usar vidrio esmerilado como una capa funcional que separa niveles de información: fondo → contexto; panel glass → contenido activo; overlays → acción inmediata.

¿Dónde funciona mejor?

En 2026, el glassmorphism encaja especialmente bien en estos contextos:

• Dashboards financieros y SaaS premium: paneles “de cristal” sobre degradados suaves o fondos oscuros, que dan sensación de producto caro sin sacrificar legibilidad si se controla bien el contraste.
• Landing pages de tech, IA y fintech: tarjetas glass sobre fondos con gradientes y partículas para transmitir innovación y cierto futurismo sobrio.
• Interfaces de sistemas operativos y ecosistemas Apple-like: translucencias coherentes, animadas con cuidado, que refuerzan la idea de capas y jerarquías.
• El patrón que se repite: glass en elementos clave (cards, modales, navs), nunca en toda la interfaz al completo, y siempre apoyado por tipografía muy clara y color bien controlado.

Glassmorphism vs “Liquid Glass”

Una de las evoluciones más interesantes es “Liquid Glass”: una versión más dinámica del glassmorphism clásico.
En lugar de un blur estático, el “vidrio” responde a luz, movimiento y contenido cercano, con pequeños cambios en refacción, brillo o sombra.
El objetivo no es sorprender, sino apoyar la estructura de la interfaz: que el usuario entienda qué está en primer plano, qué es contexto y qué se puede tocar.
Si en 2021 el glassmorphism era casi un filtro estético, en 2026 se exige que aporte además claridad y feedback.

Buenas prácticas

Los estudios de UX advierten de que el glassmorphism puede generar problemas de contraste y legibilidad si se abusa.
Las recomendaciones que más se repiten son:

• Moderación: elegir unos pocos elementos para aplicar el efecto (paneles, tarjetas, barra lateral), dejando bloques de fondo limpio para que el ojo descanse.
• Contraste suficiente: usar opacidades y desenfoques que aseguren ratios de contraste aceptables entre texto y fondo, especialmente en tamaño de cuerpo y labels.
• Capas claras: definir un sistema de niveles (fondo, superficie glass, foreground) y ser consistente en toda la interfaz.
• Sobreusarlo —por ejemplo, convertir cada botón en una píldora de cristal sobre un fondo saturado— genera ruido visual y cansa rápido, sobre todo en productos que se usan muchas horas al día.
• Combinarlo con tipografías fuertes y legibles
• Limitar la paleta a pocos tonos y dejar que el vidrio trabaje con luz y sombra, en lugar de usar degradados excesivos.
• Acompañarlo de microinteracciones sutiles (fade, ligera escala, sombras dinámicas) que refuercen la sensación de profundidad.

Ejemplo de Glassmorphism con CSS

Te dejo un ejemplo CSS completo de una card listo para pegar, con HTML mínimo para probarlo. Descárgalo en el botón de la Card.

Primero lo básico: ¿qué diferencia hay exactamente?

El diseño responsive reacciona al entorno. El tamaño de la pantalla, la orientación, la resolución. Cosas que el dispositivo define y que el usuario no cambia durante la sesión.

El diseño adaptativo reacciona al comportamiento. Lo que el usuario está haciendo ahora mismo: si está en modo lectura concentrada, si está haciendo scroll rápido buscando algo, si acaba de entrar en un formulario para rellenar un dato, si lleva dos minutos sin moverse.

Son complementarios, no excluyentes. Un componente puede —y debería— ser las dos cosas: que se recoloque bien en cualquier viewport y que además reaccione al usuario dentro de ese viewport.

Las señales que el usuario emite sin saberlo

El navegador recibe información del usuario constantemente. La mayoría de esa información la ignoramos porque para maquetar con breakpoints no la necesitamos. Pero si empiezas a pensar en diseño adaptativo, son exactamente las señales que te interesan.

Velocidad de scroll

• Scroll lento = leyendo
• Scroll rápido = buscando

Foco en un campo

• Cuando el usuario entra en un input, está en modo tarea. No está explorando, está completando algo.

Hover con intención

• Un cursor que se detiene sobre algo no es lo mismo que uno que simplemente pasa por encima.

Inactividad

• Si el usuario lleva tiempo sin moverse, puede estar leyendo muy concentrado o puede haberse ido.

Cada una de estas señales tiene un valor distinto según el tipo de componente. No todas las señales son igual de útiles para cualquier caso. Lo importante es saber cuáles tienen sentido para lo que estás diseñando y cuáles no.

Qué puede cambiar en un componente según el estado

Aquí es donde el diseño adaptativo se vuelve interesante. Hay varias dimensiones en las que un componente puede cambiar sin que el usuario tenga que hacer nada explícitamente:

La estructura visual

Un card que en modo lectura muestra imagen grande, título y extracto puede reducirse a thumbnail mínimo y título cuando detecta scroll rápido. El usuario puede escanear más rápido, hay menos ruido visual, y la información que necesita en ese momento sigue estando ahí.

Las acciones disponibles

No tiene sentido mostrar acciones secundarias (guardar, compartir, etiquetar) mientras el usuario está navegando. Tiene mucho más sentido revelarlas cuando hay una señal clara de que el usuario está considerando interactuar: ha parado el cursor sobre el elemento durante un momento, ha hecho scroll hasta detenerse justo ahí.

El nivel de detalle

En modo escaneo, el usuario necesita información jerarquizada y rápida de leer. En modo lectura concentrada, puede absorber más contexto. Un componente que ajusta la densidad de información según el modo de uso es objetivamente más útil que uno que siempre muestra lo mismo.

El énfasis visual

Cuando el usuario entra en modo tarea —ha activado un formulario, está rellenando algo— el resto de la interfaz puede ceder protagonismo. Reducir el contraste de los elementos de alrededor, simplificar el entorno visual, dejar el foco donde tiene que estar. No hace falta que nada desaparezca, basta con que se quite de en medio.

El componente en cuatro estados: demo

El mismo card, cuatro comportamientos distintos según lo que el usuario está haciendo. Ninguno de estos cambios requiere que el usuario haga nada: la interfaz los detecta sola.

Reposo

Dos columnas, imagen y contenido. Las acciones no se muestran todavía.

Scroll rápido

El componente se reduce al mínimo escaneable: thumbnail pequeño y título.

Hover con intención

Layout expandido, más contexto y acciones visibles.

Modo tarea

El componente señala el estado activo y muestra las acciones disponibles.

¿En qué tipo de componentes tiene sentido aplicar esto?

No todo necesita ser adaptativo. Hay componentes donde añadir esta capa de complejidad no aporta nada y solo complica el diseño. Y hay otros donde marca una diferencia real en la experiencia.

El equilibrio que hay que encontrar

Aquí está la trampa en la que es fácil caer: más adaptabilidad no siempre es mejor experiencia. Un componente que cambia demasiado, demasiado rápido, o por señales demasiado débiles, genera exactamente lo contrario de lo que buscas: una interfaz que parece nerviosa e impredecible.

Hay un principio que conviene tener siempre presente: el coste del cambio tiene que ser proporcional a la señal que lo desencadena.

Un cambio sutil —que el thumbnail se reduzca ligeramente, que una acción aparezca con una transición suave— puede responder a señales débiles como la velocidad de scroll. Un cambio mayor —que el componente cambie completamente de estructura— necesita una señal clara e intencional: el usuario se ha detenido, ha entrado en modo foco, ha decidido interactuar.

Si el usuario nota que la interfaz cambia sola sin entender por qué, hay un problema de diseño, no de implementación. El cambio tiene que sentirse natural, como si el componente simplemente hubiera adivinado lo que el usuario necesitaba en ese momento. Cuando eso funciona bien, el usuario no lo percibe como un cambio: simplemente siente que la interfaz funciona.

Cómo encaja esto con el diseño actual de componentes

La buena noticia es que pensar en términos de estados de comportamiento no rompe con ningún flujo de trabajo habitual. Es más bien una capa de decisiones que añades encima del diseño responsive que ya haces.

En la práctica, significa que cuando diseñas un componente, además de pensar en cómo se ve en mobile, tablet y desktop, piensas también en cómo se ve en reposo, en modo escaneo, en modo lectura activa y en modo tarea. Son cuatro preguntas más, no cuatro proyectos distintos.

Herramientas como Figma ya permiten trabajar con variantes de componentes que pueden representar estos estados. El salto de diseñar con breakpoints a diseñar con estados de comportamiento es conceptual, no técnico.

¿Cómo se implementa todo esto?

A través de CSS y JS, mostramos una capa u otra. El JS actualiza el atributo del elemento — por ejemplo data-state=»scroll» — y el CSS ya tiene escrito de antemano qué aspecto tiene el componente en cada uno de esos estados. El JS dice «ahora estás en este estado», y el CSS se encarga de todo lo visual.
Es una distinción sutil pero importante: el JS gestiona el qué (en qué estado está el componente), el CSS gestiona el cómo (cómo se ve ese estado). Nunca se cruzan.

La arquitectura que mejor funciona cuando se trabaja con componentes adaptativos separa el trabajo en tres capas que nunca se mezclan.

La primera es la detección de señal: algo escucha lo que el usuario está haciendo — si se ha movido el cursor, si ha empezado a escribir, si el scroll ha superado cierta velocidad — y recoge esa información.
La segunda es la gestión de estado: esa señal se traduce en un estado concreto del componente, que puede ser reposo, escaneo, hover con intención o modo tarea, y ese estado queda registrado en el propio elemento.
La tercera es la presentación: el componente se ve de una forma u otra dependiendo del estado en el que esté, y solo por eso. Lo importante de este esquema es lo que no ocurre: la capa de detección no decide cómo se ve nada, simplemente informa. Y la capa de presentación no sabe nada de comportamientos ni de usuarios, solo sabe que el componente está en un estado determinado y actúa en consecuencia.

Cuando estas tres capas están bien separadas, cambiar el comportamiento de un componente no obliga a tocar su visual, y cambiar su apariencia no afecta a la lógica que lo gobierna. Es la misma filosofía que lleva décadas funcionando en el desarrollo front-end bien hecho, aplicada ahora a algo que va más allá del layout.

• Guía completa de tamaños UI responsive
• Tipografías para diseño web en 2026

Bento Grid, orden y jerarquía

Su mayor ventaja es que combinan orden y variedad: puedes destacar una pieza importante con un bloque grande y acompañarla de módulos más pequeños para el resto del contenido. Eso ayuda a dirigir la atención del usuario y a que la página no se sienta repetitiva.

Lo mejor de Bento Grid frente a layouts más tradicionales es que ordena mucha información sin que la página parezca una lista larga: permite dar más peso a lo importante, mezclar tipos de contenido y crear una jerarquía visual muy clara. También funciona muy bien para productos, portfolios y landings porque hace la interfaz más atractiva y facilita el escaneo rápido del contenido.

Lo peor es que no siempre es la mejor solución: si el contenido es largo, secuencial o necesita lectura continua, Bento Grid puede romper el flujo y hacer la página menos cómoda de recorrer. Además, si se usa solo por tendencia o sin definir bien qué bloque es prioritario, puede volverse caótica y perder claridad.

¿Cuándo utilizar Bento Grid?

Funcionan especialmente bien en:

• Portfolios, para mostrar proyectos con jerarquía visual.
• Páginas de producto, para resumir funcionalidades y beneficios, presentar varios mensajes clave a la vez.
• E-commerce, para categorías, promociones y productos destacados.
• Homepages editoriales o de marca, cuando quieres reforzar una estética moderna y cuidada o construir una homepage con más personalidad.

Plantillas y recursos

Si buscas inspiración o plantillas, hay bibliotecas y galerías específicas de Bento Grid, como recopilaciones de diseño y componentes listos para usar en Figma y React. También existen colecciones visuales y bancos de ejemplos para explorar composiciones antes de diseñar la tuya.

• BentoGrids.com: galería curada de inspiración visual para ver composiciones reales.
• Figma Community: hay plugins y archivos como Bento Grids Design y Xpace Bento, útiles para generar o editar layouts rápidamente.
• Magnific: tiene recursos gráficos, vectores y plantillas relacionadas con Bento Grid.
• Behance: buena fuente para ver proyectos y referencias de diseño más elaboradas.
• Adobe Stock: útil si buscas plantillas más “stock” o presentaciones tipo slideshow con ese estilo.

Uso de Bento Grid en mobile

Un Bento Grid organiza el contenido en módulos de distintos tamaños dentro de una retícula común, de forma que una tarjeta importante puede ocupar más espacio y otras piezas secundarias quedan subordinadas visualmente. En móvil no conviene intentar replicar la composición compleja de desktop, sino reinterpretarla en una sola columna o en bloques apilados con relaciones claras de tamaño y prioridad.

¿Cómo diseñarlo?

Para mobile, suele funcionar mejor partir de una base de una columna principal, con separación constante entre tarjetas y con diferencias de tamaño logradas por altura, no por exceso de columnas. También conviene mantener paddings homogéneos dentro de cada módulo y usar cards con contenido muy delimitado — título, texto breve, imagen o CTA — para que la cuadrícula siga siendo fácil de escanear.

Medidas útiles

Como punto de partida para una web app o landing mobile con Bento Grid, puedes usar esta base:

• Margen lateral: 16–24 px
• Gap entre bloques: 12–16 px
• Padding interno de cada card: 16–24 px
• Radio de borde consistente en todos los módulos
• Una tarjeta “destacada” al inicio, seguida por módulos secundarios más compactos

Ese enfoque mantiene la lógica modular del Bento sin convertir la pantalla móvil en un mosaico incómodo.

Diferencias de Bento con otras grids

Bento Grid se diferencia de una grid tradicional porque no trata todos los bloques igual. En lugar de repartir el contenido de forma uniforme, usa módulos de distinto tamaño para dar más peso a unas piezas que a otras. Eso hace que la composición tenga más ritmo y que la atención se dirija con más claridad hacia lo importante.

Qué cambia respecto a una grid clásica

Una grid tradicional suele priorizar la regularidad. Las columnas tienen un comportamiento más estable y el contenido se distribuye de forma bastante homogénea. Bento Grid, en cambio, introduce variación visual: un bloque puede ser más grande, otro más compacto y otro ocupar una posición más protagonista dentro del conjunto.

Esa diferencia cambia bastante la sensación de la interfaz. Bento Grid se percibe como algo más editorial, más pensado y más visual. La grid clásica, en cambio, transmite más orden, más neutralidad y más continuidad.

Cuándo funciona mejor

Bento Grid suele funcionar mejor cuando quieres mostrar varios tipos de contenido a la vez: texto, imagen, métricas, beneficios o llamadas a la acción. Es una muy buena opción para homepages, portfolios o secciones de producto donde la presentación importa tanto como el contenido.

Una grid tradicional encaja mejor cuando el contenido es más repetitivo o necesita una lectura más lineal. Por ejemplo, listados, catálogos, bloques informativos o estructuras donde la prioridad es que todo se lea rápido y sin sobresaltos.

En realidad, la diferencia principal no es solo estética. Bento Grid ayuda a construir jerarquía visual, mientras que una grid más clásica apuesta por la consistencia. Una destaca, la otra ordena. Y dependiendo del tipo de página, una u otra puede tener más sentido.

Tipografías que merece la pena mirar

La tipografía cambia por completo el tono de un diseño. No es solo una cuestión estética: también afecta a la lectura, la jerarquía visual y la personalidad de una web o una pieza digital.

Fotos gratuitas y bancos útiles

Las fotos siguen siendo uno de los recursos más usados en diseño digital, sobre todo en webs corporativas, landings y piezas promocionales. Si necesitas imágenes de calidad sin pagar licencia desde el principio, hay varias opciones bastante conocidas que siguen funcionando muy bien.

Texturas y fondos con más carácter

Las texturas son un recurso muy interesante cuando quieres dar profundidad sin recargar. Sirven para fondos, overlays, composiciones más editoriales o interfaces que necesitan un punto más táctil y menos plano.

Vectores, iconos e ilustraciones

Cuando el proyecto necesita elementos gráficos más flexibles, los vectores siguen siendo una de las mejores soluciones. Funcionan bien porque escalan sin perder calidad y se adaptan mejor a distintas pantallas y formatos.

Mockups y recursos UI

Plantillas, interfaces, dispositivos y recursos visuales que vienen muy bien para presentar proyectos, probar ideas o completar diseños sin empezar desde cero.

Textos

Elige bien o pierde usuarios, la regla #1: Nunca más de 3 familias.

Tipografías (mis preferencias)

• INTER – Diseñada para interfaces. x-height perfecta, pesos variables, legible a 12px. Ideal para Body + headings. Carga ligera. La tienes en Google fonts
• GEIST – Moderna, neutra, optimizada para código/números. Alternativa a SF Pro. Ideal para Dashboards y SaaS.
• SATOSHI – Sans geométrica suave, gran contraste de pesos. Se siente premium sin ser «de diseño». Ideal para titulares y body.
• JETBRAINS MONO – Monospaced perfecta para tablas/metrics, números, código, KPIs.
• TT Interfaces Pro – Hecha para UI móvil. Espaciado perfecto, legible 10px+.

Consulta aquí más información sobre las fuentes más utilizadas en 2026

Jerarquía:

Lo ideal es usar clamp() para obtener un responsive automático. clamp(MÍNIMO, IDEAL, MÁXIMO)

• MÍNIMO – el tamaño mínimo que va a tener la fuente (móviles pequeños)
• IDEAL – crece con el vw (Viewport Width) es una unidad de medida relativa al ancho de la ventana gráfica (o «viewport») del navegador. 1vw equivale exactamente al 1% del ancho del viewport.
• MÁXIMO – el tamaño máximo (en un desktop grande)

Separaciones (padding)

Para web apps, la referencia más sólida y repetida en guías de diseño es trabajar con una base de múltiplos de 4 px o 8 px para márgenes y paddings, porque ayuda a mantener coherencia visual y escalabilidad; Microsoft, por ejemplo, recomienda que dimensiones, márgenes y rellenos estén en múltiplos de 4 px en sus guías de diseño de UI. Además, varias guías prácticas de CSS coinciden en que el padding debe usarse para dar aire interno al contenido y mejorar legibilidad, especialmente en componentes como botones, tarjetas y formularios

En pantallas pequeñas, el padding lateral mínimo suele ser 16 px, porque menos que eso empieza a hacer que el contenido se vea apretado; en interfaces más cuidadas, 20–24 px laterales suelen funcionar mejor para lectura y jerarquía visual. En botones, un padding interno típico cómodo puede rondar 12 px vertical y 16–20 px horizontal, siempre que el área táctil total siga siendo suficientemente grande.

Elementos interactivos

Para elementos interactivos en mobile, la clave es diseñarlos para el dedo y no para el cursor: los objetivos táctiles deberían quedarse en 44 x 44 px como mínimo según Apple y en 48 x 48 dp según Google, con al menos 8 px de separación entre elementos para reducir toques accidentales. Además, WCAG 2.2 exige un mínimo de 24 x 24 CSS px o espacio suficiente alrededor, pero para una web app móvil usable conviene moverse por encima de ese mínimo técnico.
Tamaño y toque
Los botones principales funcionan mejor con una altura de 48–56 px, porque se pulsan con más comodidad en uso real y dan más presencia visual a la acción principal. Los icon buttons pueden mostrar un icono de 20–24 px, pero su área tocable completa debería seguir respetando el mínimo táctil, añadiendo padding o un contenedor mayor.

Espaciado y jerarquía

Entre controles interactivos, deja al menos 8 px de aire horizontal y vertical, y si el control es pequeño, crea una “zona de exclusión” alrededor para evitar errores de pulsación. En mobile también ayuda trabajar con una jerarquía muy clara: una sola acción principal visible, contraste suficiente y una separación generosa entre bloques para que la interfaz no se sienta apretada.

Formularios y estados

En formularios móviles, los campos deberían tener una altura mínima de 44–48 px, labels visibles y validación inmediata por campo para que el usuario entienda qué pasa sin releer toda la pantalla. También es importante que cada interacción devuelva feedback claro — cambio de estado, validación, carga o confirmación — porque en mobile esa respuesta visual reduce incertidumbre y mejora la percepción de fluidez.

Maquetación útil

Para una web app móvil, suele funcionar bien este punto de partida:

Ese sistema hace que la interfaz sea más cómoda, más legible y más fiable al tocar, que es justo lo que más pesa en una web app pensada para móvil

Mi caso real: un blog veterano, entradas viejas… y un borrado demasiado alegre

Hace unos 20 años que tengo este blog, con cientos de artículos sobre diseño web, UX, WordPress, trucos de código y pequeños experimentos. Como pasa en casi todos los proyectos que sobreviven al tiempo, parte de ese contenido se fue quedando obsoleto: tecnologías que ya no se usan, capturas de interfaces que han cambiado, formas de trabajar que hoy no representan nuestro trabajo.

El blog llevaba mucho tiempo sin actualizarse y en un momento dado decidí “hacer limpieza”, borrar todo y empezar de nuevo.

¿Qué no miré?

• Si seguían recibiendo visitas desde Google.
• Si tenían enlaces externos desde otros blogs o foros.
• Si eran la única respuesta que yo daba a ciertas búsquedas long tail.

Resultado:

• Páginas 404 repartidas por la web.
• Pérdida de tráfico en búsquedas donde esas entradas todavía respondían bien a lo que preguntaban los usuarios.
• Señales SEO desperdigadas que podrían haberse reciclado en contenidos mejores.

¿Qué debería haber hecho antes de borrar?

Cada vez que te plantees borrar una página concreta de tu web (una entrada del blog, una landing antigua, una página de servicio que ya no ofreces), haz estas consultas:

1. ¿Sigue recibiendo visitas?
   Entra en tu herramienta de analítica (Google Analytics o similar) y mira:
   – Sesiones de los últimos 3–6 meses.
   – Si esa URL aparece como página de entrada desde buscadores.
   Una página con visitas constantes merece una segunda oportunidad antes de desaparecer.
2.  ¿Existen enlaces externos que me estén generando visitas?
   Entra en Google Search Console → Informe de enlaces (backlinks que detecta Google), y valora si te merece la pena o no.
3. Revisa también los enlaces internos
   También en Search Console, en “Enlaces internos” puedes detectar si esa URL tiene bastante enlazado interno, y en tu propio WordPress puedes buscar la URL en el buscador del editor o en el listado de entradas/páginas.
4. Decide la acción (actualizar, fusionar, redirigir, eliminar)
   Con esos datos en la mano, decides en función del valor que aún tenga: actualizar el contenido, fusionarlo con otro post, crear una redirección 301 desde tu plugin de SEO (Rank Math, Yoast, etc.) o devolver un 410 desde el mismo plugin o el servidor.

¿Cómo lo solucioné?

En mi caso, al llevar tantos meses sin actualizar, las visitas habían bajado mucho, pero aún así había páginas bien posicionadas que estaban generando errores 404, página no encontrada. Lo que hice fue mirar las cifras para atacar aquellas url’s que mereciese la pena recuperar.

1. Páginas bien posicionadas
   Volví a crear otra página con la misma URL, Google la tratará como una página “actualizada/reemplazada” cuando vuelva a rastrearla, no como una URL completamente nueva desde cero. Al haber mantenido la misma url, se conserva el histórico de señales asociado (enlaces entrantes, menciones, autoridad acumulada), y el buscador reevalúa si el nuevo contenido merece mantener o mejorar el ranking.
2. Usar redireccionamientos 301
   Al usar este redireccionamiento, le estoy diciendo que es una redirección permanente. Le dice a Google «esta página se ha movido para siempre, pasa todo el link juice aquí».  Transfiere casi el 100% de la autoridad de la URL antigua a la nueva. Lo utilicé para todas aquellas entradas residuales que tenían alguna relación con nuevos post que he escrito.
3. Crear una página 404
   Cuando un visitante llega a una URL rota o inexistente, una página 404 estándar genera frustración y un rebote inmediato (hasta 80% en algunos casos). Una versión explicativa ofrece disculpas claras, explica el error de forma amigable y propone soluciones rápidas, esto reduce la tasa de rebote y mantiene al usuario navegando.

Redireccionamiento 301 en WordPress

Existe un plugin que a mi me gusta mucho, se llama Redirection, muy sencillo, registra logs y funciona. Únicamente tienes que escribir la url antigua, la nueva y guardar. Tienes hasta 1.000 redirecciones en la versión gratis.

En conclusión

Borrar un blog entero no es necesariamente un desastre SEO si después haces una migración inteligente: conservar lo que tiene valor, redirigir lo que tiene sustituto y retirar correctamente lo que ya no aporta. En cambio, borrar sin mapa, sin equivalencias y sin control de estados HTTP sí puede hacer que pierdas tráfico, autoridad y señales acumuladas. El éxito depende de la precisión de cada URL y del seguimiento posterior en Search Console.