- El CSS no es un factor de ranking directo, pero decide cuándo se pinta la página y qué ve Google al renderizarla. Por ahí llega a tus Core Web Vitals y a tu indexación.
- Por defecto, el CSS bloquea el render. En una prueba propia con un retardo artificial de 400 ms por hoja, el primer pintado tardó unos 40 ms con el CSS en línea, 440 ms con una hoja externa y 830 ms cuando la segunda hoja entraba por
@import. - Lo que importa de verdad es lo que pesa y lo que bloquea: minificar ayuda poco (en mi caso un 4,7 % en bruto), comprimir ayuda más y quitar CSS que la página no usa ayuda más que ambas.
- Ocultar contenido en acordeones o pestañas es legítimo; ocultarlo con texto blanco, fuera de pantalla o con tamaño cero es spam según las políticas de Google.
- El texto generado con
::beforeo::afterno está en el DOM y, según Google, no llega a indexarse: lo decorativo, bien; lo que quieres posicionar, en el HTML. - No bloquees en robots.txt los CSS que la página necesita para verse bien; Google los usa para renderizar.
Cuando se habla de CSS y SEO casi siempre se reduce a «minifica tus estilos». Es uno de los consejos con menos retorno. Lo que sí cambia el resultado es cuántos bytes de CSS se descargan antes del primer pintado, si esa descarga depende de otra descarga y qué contenido real se esconde o se inventa desde la hoja de estilos.
Aquí separo las cosas que afectan al rendimiento de las que afectan a la indexación, y las pruebo en lugar de repetirlas: mido el CSS de mi propia web y reproduzco en local el coste del bloqueo y del @import. Donde Google no ha documentado algo, lo digo.
Qué hace el CSS por tu SEO y qué no
El CSS no posiciona. Lo que hace es intervenir en tres sitios donde sí se decide algo: el tiempo hasta el primer pintado (y con él el LCP y el CLS), la versión de la página que ve Googlebot cuando la renderiza y la cantidad de recursos que hay que pedir para llegar a ella.
Google lo trató en un episodio del podcast Search Off the Record, «How does CSS affect SEO?», del 24 de julio de 2025, con Martin Splitt y John Mueller. Lo que sé de su contenido me llega a través de resúmenes de prensa especializada, no de una transcripción oficial, así que lo atribuyo a ese episodio y lo marco cuando lo uso. Lo que sí tiene respaldo en documentación oficial lo cito con su fuente. Para el rendimiento en sí, el marco de medida son los Core Web Vitals.
| Efecto | Dónde se ve | Documentación |
|---|---|---|
| Retraso del primer pintado | FCP y LCP | web.dev: el CSS es un recurso que bloquea el render por defecto |
| Saltos de maquetación | CLS | web.dev: reservar espacio con width, height o aspect-ratio |
| Contenido oculto con intención de engañar | Acción manual o filtros de spam | Políticas de spam de Google |
| Texto generado desde CSS | Indexación | No documentado en la ayuda; lo comentan Mueller y Splitt en el podcast |
| CSS bloqueado en robots.txt | Renderizado | Documentación de robots.txt: no bloquees recursos de los que depende la página |
El CSS bloquea el render: qué significa y cuánto cuesta
web.dev lo dice sin rodeos: por defecto, el CSS se trata como un recurso que bloquea el render. El navegador no pinta hasta tener el DOM y el CSSOM, porque pintar sin estilos produciría un destello de contenido sin formato (FOUC). «Bloquear el render» solo significa que el navegador retiene el primer pintado; sigue descargando todo el CSS, bloqueante o no, aunque con menos prioridad el que no bloquea.
Sirve para marcar una hoja como no bloqueante el atributo media: media="print" no bloquea la carga inicial y, en cambio, media="all" (o ningún atributo) sí. Una consulta como orientation:portrait se evalúa en carga, de modo que bloquea o no según el dispositivo.
Para ver el coste con números, monté una prueba en local. Un servidor HTTP mínimo que retrasa 400 ms cada archivo .css, Chromium con Playwright y cinco páginas casi idénticas: tres veces cada una y el First Contentful Paint de cada carga.
| Variante | FCP medido (3 cargas) | Qué pasó |
|---|---|---|
CSS en un <style> en el HTML | 32 a 44 ms | Sin peticiones de CSS |
Una hoja externa en <link> | 440 a 456 ms | El FCP espera a que termine la hoja (400 ms más la latencia) |
Dos hojas externas en <link> | 440 a 444 ms | Se piden en paralelo, así que no suman |
Una hoja que importa otra con @import | 828 a 852 ms | La segunda empieza cuando termina la primera: se suman |
Una hoja con media="print" y onload que la pasa a all | 28 a 48 ms | Pinta pronto, pero sin esos estilos hasta que llega la hoja |
Son números de laboratorio con un retardo artificial, no una predicción para tu servidor. Lo que enseñan es la forma: una hoja externa suma su tiempo de descarga al primer pintado, dos hojas en paralelo no suman, y una cadena sí. En la última fila, el FCP baja porque el texto se pinta sin CSS; una cifra de FCP baja no garantiza una buena experiencia si la página se ve rota durante ese tiempo.
CSS crítico en línea o hoja externa
La salida habitual al bloqueo es poner en el <head> el CSS que hace falta para lo que se ve al cargar y diferir el resto. Chrome lo recomienda así para las peticiones críticas pero pequeñas, y su guía sobre peticiones que bloquean el render sugiere reducir el CSS a lo necesario para el primer pintado. Pero tanto Chrome como web.dev avisan de lo mismo: es una técnica avanzada, que puede introducir errores y que la mayoría de los sitios alcanzan sus objetivos sin ella.
Las dos opciones tienen un coste distinto:
- Hoja externa: se cachea de forma independiente y se reutiliza entre páginas, pero cada visita sin caché paga una petición bloqueante. Cómo configurar esa caché lo expliqué en el artículo sobre caché para Googlebot y usuarios.
- CSS en línea: sin petición de por medio, pero viaja otra vez dentro del HTML de cada página y no se reutiliza entre ellas. Con un CSS grande, eso engorda el documento.
El método de web.dev para extraer el crítico es la pestaña Coverage de DevTools: se recarga la página, se copian al <style> las reglas que cuentan como usadas y se carga el resto de forma asíncrona. Su patrón es rel="preload" as="style" con onload que cambia rel a stylesheet, más un <noscript> de respaldo; web.dev recomienda emplear una librería como loadCSS en producción y advierte de que un onload en línea puede chocar con una Content Security Policy. El truco con media="print" de la tabla anterior no aparece en esa guía; yo lo he probado, pero no lo recomiendo sin comprobar el destello sin estilos. Cómo funciona preload y cuándo conviene lo explico en el artículo de precarga de recursos, y para subir o bajar prioridades de descarga hay otro sobre fetchpriority.
@import: la cadena que casi siempre sobra
La regla @import carga una hoja desde otra. MDN fija una condición de sintaxis: tiene que ir al principio de la hoja, antes de cualquier otra regla salvo @charset y @layer, o se ignora. Lo que no dice es nada sobre rendimiento. Eso lo mostró mi prueba: la hoja importada no se pide hasta que el navegador ha descargado y leído la que la importa, de ahí que el primer pintado pasara de unos 440 ms a unos 830 ms.
En un proyecto real, esa cadena se corta con dos <link> en el HTML (se descargan en paralelo) o, mejor, con un paso de compilación que concatene los archivos. Si usas @import de fuentes de un tercero, la cadena además cruza un origen distinto.
Peso: minificación, compresión y CSS que no se usa
Un CSS pequeño se descarga y se interpreta antes. Tres palancas, de menos a más retorno.
Minificar
Lighthouse lo describe como quitar espacios y comentarios y acortar valores (#000000 a #000). Mi caso, medido: site.css pesa 101.404 bytes y su versión minificada site.min.css, 96.677; un 4,7 % menos. Es poco porque la hoja ya estaba escrita con poco relleno.
Comprimir
Ahí sí hay diferencia, porque el texto repetitivo comprime muy bien. Con gzip -9, los 101.404 bytes bajan a 19.497 y los 96.677 a 17.678; con Brotli (calidad por defecto de la librería de Python), a 16.589 y 15.186. Es decir, comprimir quita en torno a un 80 % del peso y minificar solo ahorra otro 9 % sobre el resultado comprimido. La configuración de compresión de tu servidor (mod_deflate, Brotli, el CDN) cuenta más que el minificador. Cómo se comporta eso en el borde lo cuento en el artículo sobre CDN y SEO.
Eliminar lo que no se usa
Es la palanca grande, y la más incómoda. Lighthouse enumera las hojas con 2 KiB o más de CSS sin usar y recomienda quitarlo, extraer el crítico y cargar el resto de forma asíncrona. En DevTools, la pestaña Coverage marca en gris los bytes no usados, y avisa de su límite: solo refleja lo que se aplicó durante la grabación, así que una regla de un menú que no abriste cuenta como no usada. Encontrar CSS sobrante es fácil; reorganizar para que cada página cargue solo lo suyo es lo difícil, y la propia ayuda de Chrome lo reconoce.
Sobre tamaños, Search Engine Journal recoge del Web Almanac 2022 que la mediana de CSS rondaba los 68 KB en móvil y 72 KB en escritorio; es una cifra de segunda mano, citada para contexto y no verificada por mí en el original. Los frameworks pesados de CSS (el paquete entero de un framework de componentes para usar cuatro clases) son la causa habitual de que una web la supere con holgura. Si empleas uno, purga lo que no uses con la herramienta de tu stack.
Fuentes web: font-display y fuente de reserva
Las @font-face viven en el CSS y su efecto se nota en el texto. Con font-display: swap hay periodo de bloqueo de 0 ms y de intercambio ilimitado: el texto se pinta pronto con una fuente de reserva y salta cuando llega la web. web.dev lo describe como el valor que menos retrasa el texto, pero que puede causar un cambio de diseño. optional tiene 100 ms de bloqueo y no intercambia después: no hay salto, pero la fuente web puede no usarse si llega tarde.
Para reducir el salto con swap, web.dev recomienda ajustar la fuente de reserva con size-adjust, ascent-override, descent-override y line-gap-override, y precargar las fuentes críticas. También menciona unicode-range y el subconjunto de glifos para reducir peso. La relación entre preload y crossorigin en fuentes ya está en el artículo de precarga, no la repito.
Ocultar contenido con CSS: lo permitido y el spam
Con CSS puedes esconder texto de cinco maneras (display:none, visibility:hidden, fuera de pantalla, tamaño o opacidad en cero y color igual al fondo) y Google las trata según para qué lo hagas, no según la técnica.
Las políticas de spam definen el texto oculto como contenido colocado únicamente para manipular a los buscadores y no visible para el usuario. Ponen como ejemplos el texto blanco sobre fondo blanco, el texto tras una imagen, el texto posicionado fuera de pantalla con CSS, el tamaño de fuente o la opacidad en cero, y un enlace escondido en un solo carácter. Y dejan claro lo que no lo es: acordeones y pestañas, carruseles, tooltips y texto solo para lectores de pantalla cuando mejora esa experiencia.
Sobre la indexación, la guía de mobile-first dice que puedes usar acordeones o pestañas en móvil para ahorrar espacio, siempre que el contenido sea equivalente al de escritorio. Lo que advierte es otra cosa: que no cargues contenido principal solo tras una interacción del usuario, porque Google no hace clics ni desplazamientos. Hay resúmenes del podcast de Google que atribuyen a Splitt que el contenido en display:none probablemente no se indexa; no lo he podido contrastar con el audio y choca con el permiso de los acordeones, así que lo dejo como no verificado y lo resuelvo con una prueba en Search Console (más abajo).
Mi propia web usa <details> para las preguntas frecuentes de cada artículo, la forma más simple de un acordeón. El texto de las respuestas está en el HTML aunque esté plegado, que es lo que cuenta para el contenido equivalente entre móvil y escritorio. Sobre el resto de la paridad móvil hay un artículo entero de SEO móvil.
Contenido generado con ::before y ::after
Con la propiedad content puedes insertar texto desde el CSS. Ese texto no está en el DOM. En el podcast, Mueller citó el caso de unos hashtags añadidos con :before que no llegaron nunca a los sistemas de indexación, y Splitt confirmó que no están en el DOM (según la crónica de Search Engine Journal del 25 de julio de 2025). No hay una línea equivalente en la ayuda de Search Central, así que es una declaración oral sin documento oficial detrás.
La regla práctica sale sola: la decoración puede vivir en el CSS (flechas, comillas, numeración, separadores) y todo texto que quieras que alguien lea, cite o posicione va en el HTML. Lo mismo con las imágenes: la documentación de imágenes de Google dice que no indexa las imágenes CSS, es decir, las de background-image, y que encuentra las imágenes en el atributo src de <img>, también dentro de <picture>. El detalle de cómo servirlas está en el artículo de optimización de imágenes.
CLS: dimensiones, aspect-ratio y fuentes
La parte del CLS que depende del CSS es reservar espacio. web.dev pide poner siempre width y height en imágenes y vídeos; los navegadores calculan un aspect-ratio por defecto a partir de ellos (Chrome lo muestra como aspect-ratio: auto 640 / 360) y, cuando la imagen se descarga, el auto hace que mande su relación real. Como alternativa, se puede reservar el hueco con aspect-ratio en CSS. Con srcset, todas las imágenes deben compartir relación de aspecto para que esos atributos valgan.
Las fuentes entran por el mismo sitio. web.dev señala que tanto FOUT como FOIT pueden producir saltos y que font-display: optional evita el re-layout porque la fuente solo se usa si ya está disponible en el primer renderizado. El caso práctico de combinar swap con una fuente de reserva ajustada es el que uso yo.
content-visibility y contain
content-visibility: auto hace que el navegador se salte el trabajo de estilos, maquetación y pintado de lo que está fuera de pantalla hasta que se acerca al viewport. Se combina con contain-intrinsic-size para dejar un tamaño provisional (con auto recuerda el último tamaño renderizado y evita saltos de la barra de scroll). En el ejemplo de web.dev, el render de la carga inicial bajó de 232 ms a 30 ms; el propio artículo dice que lo esperable es una reducción del 50 % o más y que depende del contenido. El soporte que indica es Chrome 85, Edge 85, Firefox 125 y Safari 18.
Para SEO, lo relevante es que el contenido sigue en el DOM y en el árbol de accesibilidad, a diferencia de visibility:hidden. Lo que web.dev no trata es el efecto sobre la indexación, de modo que no puedo afirmar nada más allá de que el texto permanece en el DOM. Es una optimización de rendimiento de renderizado para páginas largas, no una herramienta de SEO.
Responsive y CSS bloqueado en robots.txt
Un diseño adaptable necesita el meta viewport y media queries; Google indexa con la versión móvil, y de cómo se plantea eso trata el artículo de SEO móvil (viewport, tap targets, paridad). Lo del CSS en este punto se limita a no esconder en móvil lo que enseñas en escritorio.
El otro frente es robots.txt. La documentación de Google sobre robots.txt permite bloquear recursos «poco importantes» si la página no se ve afectada de forma significativa, con esta advertencia: si los bloqueas y dependen de ellos, Google no analizará bien las páginas. La guía de JavaScript añade que Google no renderiza el JavaScript de archivos o páginas bloqueados; no nombra CSS en ese punto. Resumen de Search Engine Journal sobre el podcast: Googlebot usa el CSS para renderizar como un usuario. La regla segura es no bloquear los estilos de los que depende el aspecto de la página, y el detalle del archivo está en la guía de robots.txt. Cuando el contenido depende además de JavaScript, mira el artículo de JavaScript y SEO.
Cómo tengo el CSS en mi web
Esto es lo que he medido y leído en el código de cristofercruz.net, sin añadir nada que no haya comprobado.
| Aspecto | Qué hay |
|---|---|
| Dónde va el CSS | En línea: inline_v3_styles() imprime un <style id="site-styles"> con site.min.css. No hay <link rel="stylesheet"> en las tres páginas que revisé |
| Tamaño | site.css 101.404 B; site.min.css 96.677 B (96.738 B ya en el HTML, tras sustituir las rutas de recursos) |
| Comprimido | 17.678 B con gzip y 15.186 B con Brotli (medido fuera del servidor; en el HTML llega a unos 17,8 KB con gzip) |
| Peso dentro del HTML | Cerca del 56 % del HTML comprimido en la home y del 50 % en este artículo |
| Usado por página | Entre el 21,7 % y el 35,5 % en escritorio y entre el 23,5 % y el 37,5 % en móvil |
@import, @layer, content-visibility, contain | Hoy no uso ninguno |
| Fuentes | Cinco @font-face con font-display: swap y dos fuentes de reserva con size-adjust y ascent-override; tres precargadas en la cabecera |
| Generado con CSS | Comillas, numeración con counter(), separadores y flechas; la URL tras los enlaces externos solo en @media print |
| robots.txt | No bloquea /assets/; sí /includes/, /tools/ y alguna ruta más, de donde no sale ningún CSS |
La cobertura la medí con Chromium y el protocolo de DevTools (Playwright no expone la API de coverage en Python), en tres páginas (la home, /blog/cache-seo/ y /servicios/auditoria-seo/) y dos tamaños de ventana (1440 y 390 px), con scroll hasta el final. Es un cálculo aproximado: suma de los rangos de las reglas aplicadas, sin pasar el ratón por encima y con los menús cerrados. Si abro también todos los <details> y junto las seis cargas, el uso conjunto es del 62,4 %.
La lectura es doble. Cada página descarga una hoja de la que usa menos de un tercio, porque la hoja es la del sitio entero. Pero el conjunto de páginas aprovecha casi dos tercios, así que partirla por plantillas ahorraría bytes concretos en cada una y, a cambio, me obligaría a mantener varias hojas y a perder la ventaja de no tener petición alguna. Hoy me compensa la hoja única en línea; si el CSS siguiera creciendo, lo notaría antes en los artículos, donde ya supone la mitad del HTML comprimido, que en la home.
Hay dos avisos. Primero, en el .htaccess veo mod_deflate para text/css y text/html, pero ninguna regla de Brotli: lo que sirva el hosting realmente no lo he comprobado desde fuera. Segundo, no he medido el efecto del CSS sobre el LCP en datos de campo, solo su peso y su uso.
Cómo auditar el CSS de una web
- Cuenta las hojas que bloquean. En Lighthouse (o el panel Performance de DevTools), mira las peticiones de CSS que impiden el primer pintado y cuánto tardan. Si hay una cadena, busca los
@import. - Mide el CSS no usado. Abre Coverage, recarga, recorre la página y apunta qué hojas tienen más gris. Haz lo mismo en una plantilla de cada tipo, no solo en la home.
- Comprueba el tamaño real transferido. Mira el peso comprimido en la pestaña Network y mira que el servidor comprime las hojas:
curl -sI -H 'Accept-Encoding: gzip, br' URLy la cabeceracontent-encoding. - Revisa lo que Google renderiza. En la inspección de URL de Search Console, pide la prueba en vivo y mira el HTML renderizado y la captura. Si falta contenido o el aspecto está roto, busca recursos bloqueados.
- Prueba el contenido oculto. Para texto en acordeones o pestañas, comprueba que aparece en el HTML renderizado de la inspección de URL; es la forma de resolver lo que la documentación no cierra.
- Busca contenido en
content:. Ungrepdecontent:"en tus hojas: lo que sea texto con significado debería estar en el HTML.
Antes de tocar nada, guarda una captura de Lighthouse y de Coverage. Casi toda optimización de CSS rompe algún estilo en una plantilla que nadie abrió, y sin un «antes» no sabrás si la mejora compensó.
Preguntas frecuentes
¿El CSS influye en el posicionamiento?
No como factor directo. Influye a través del rendimiento (el CSS bloquea el render por defecto y puede empeorar LCP y CLS) y de lo que Google ve al renderizar la página. En una auditoría completa, revisarlo forma parte del servicio de auditoría SEO que ofrezco.
¿Conviene poner el CSS en línea o en un archivo externo?
Depende del tamaño. Un CSS pequeño en línea evita una petición bloqueante; uno grande engorda cada HTML y no se reutiliza. Chrome y web.dev avisan de que extraer y aplazar el CSS crítico es una técnica avanzada y que muchas webs cumplen sin ella.
¿Es malo usar @import?
Suele sobrar. En mi prueba con 400 ms de retardo por hoja, el primer pintado pasó de unos 440 ms a unos 830 ms, porque la hoja importada no se pide hasta terminar la primera. Dos <link> se descargan en paralelo.
¿Google indexa el texto de un acordeón o una pestaña?
La documentación de mobile-first dice que puedes usarlos en móvil con contenido equivalente al de escritorio, y las políticas de spam dejan claro que no son texto oculto. Lo que no debes hacer es cargar el contenido principal solo tras un clic. Compruébalo en el HTML renderizado de Search Console.
¿Se indexa el texto que añado con ::before o ::after?
Según Mueller y Splitt en el podcast Search Off the Record, no: ese contenido no está en el DOM. No lo he visto en la ayuda oficial, así que trátalo como una declaración oral. Ponlo en el HTML.
¿Puedo bloquear mis CSS en robots.txt?
Solo los poco importantes. La documentación de Google advierte de que, si bloqueas recursos de los que depende la página, Google no la analizará bien. Lo seguro es no bloquear los estilos que cambian su aspecto.
¿Merece la pena minificar el CSS?
Es útil pero pequeño: en mi hoja ahorra un 4,7 % en bruto y un 9 % tras comprimir. La compresión del servidor y quitar CSS que no se usa pesan más.
Referencias y fuentes
Documentación consultada para este artículo.
- Render-blocking CSS web.dev · Google
- Defer non-critical CSS web.dev · Google
- Spam policies for Google web search Google Search Central
- Mobile-first indexing best practices Google Search Central
- Introduction to robots.txt Google Search Central
- Google Images SEO best practices Google Search Central
- content-visibility: the new CSS property that boosts your rendering performance web.dev · Google
- Optimize Cumulative Layout Shift web.dev · Google
- Best practices for fonts web.dev · Google
- Reduce unused CSS Chrome for Developers · Lighthouse
- How does CSS affect SEO? Search Off the Record · Google
- Google confirms CSS class names don’t influence SEO Search Engine Journal
