Mobile SEO: Optimización para crear un sitio compatible con móviles
Por Carlos Sanchez
Autor invitado
¿Qué es el mobile SEO?
El mobile SEO, o SEO móvil, es el proceso de optimización de la versión móvil de un sitio web para atraer tráfico orgánico desde los motores de búsqueda. La optimización móvil se centra en ofrecer la mejor experiencia en dispositivos móviles, donde las implementaciones técnicas, como el uso del diseño responsivo, desempeñan un papel fundamental.
¿Por qué es importante el mobile SEO?
Según Statista, los dispositivos móviles generaron el 52.27% del tráfico móvil mundial en el primer trimestre de 2026.
No son solo los usuarios los que ven de forma predominante tu sitio desde un dispositivo móvil, sino también Googlebot.
En 2016, Google anunció la indexación mobile-first. Como resultado, Google rastrea la web principalmente a través del agente de usuario para smartphones Googlebot. Esto significa que Google utilizará principalmente la versión móvil del contenido para la indexación y el ranking.
En este artículo se explicarán las diferentes configuraciones que se pueden aplicar en una página web para que estén adaptadas al móvil tanto para Google como para los usuarios, por lo que te servirán de cada a auditorías SEO, pero además enseñaré distintos trucos que te pueden ayudar por mucho a mejorar tu configuración.
Configuraciones clave para un buen SEO móvil
En primer lugar veremos los distintos tipos de configuraciones que puedes aplicar de cara a una web, algunos más utilizados que otros, pero prefiero explicar todas las casuísticas para que aprendas a identificarlos, si trabajas como SEO nunca se sabe cuando te puede tocar revisar una web con cualquiera de estos estilos.
Nota al margen
Se debe tener mucho cuidado porque en Español a veces se traduce de una forma en la que da lugar a confusión. Como los términos vienen del inglés, yo voy a usar la terminología original.
Como se puede observar, hasta en la traducción de la documentación de Google el término puede dar lugar a confusión, ya que al responsive se le denomina en Español diseño adaptable, mientras que el término Adaptive (AWD) en inglés se usa para la gestión de User-Agents.
Por lo que para este artículo utilizaremos Responsive para referirnos la redistribución del contenido por medio de CSS y Adaptive al cambio de contenido por medio de user-agents. Y es importante definirlo antes de profundizar para evitar confusiones bastante habituales.
Responsive
El responsive a día de hoy es la forma más común de hacer una web para móviles.
Básicamente consiste en hacer un sólo HTML para todo tipo de dispositivos y adaptar únicamente la interfaz visual por medio de CSS con la función @media.
De esta forma los mismos elementos HTML tienen un aspecto o tamaño diferente dependiendo del ancho y alto del dispositivo.
Generalmente se utilizan unos “breakpoints” de referencia para que en lugar de adaptar el diseño a todo tipo de dispositivos inexistentes se adapte a los más comunes.
¿Por qué usar responsive?
- Google recomienda este tipo de implementación, pero ojo, no porque sea automáticamente mejor que el resto, sino porque es más fácil de implementar y mantener ya que sólo tienes que actualizar el contenido y el código en un lugar. Esto reduce drásticamente la posibilidad de cometer errores comunes en SEO, como desajustes de contenido entre la versión de escritorio y la móvil.
- Prevención de contenido duplicado: Al existir una única URL para todos los dispositivos, ahorrándote problemas de canonicalización complejos o de tener que gestionar redirecciones engorrosas dependiendo del dispositivo.
- Preparado para el futuro (Flexibilidad fluida): Dado que se basa en el ancho de la pantalla y no en el tipo de dispositivo, la web se verá bien en pantallas de tamaños que quizás aún no son populares (nuevos modelos de tablets, pantallas plegables, smart TVs).
Adaptive
Con la metaetiqueta de viewport, se indica al navegador cómo debe ajustar las dimensiones y la escala de la página a la anchura del dispositivo. Si no se incluye esta metaetiqueta, se procesa automáticamente la página con una anchura de pantalla propia de ordenadores en los navegadores para móviles (por lo general, unos 980 px, aunque puede variar según el dispositivo). A continuación, se intenta mejorar el aspecto del contenido en los navegadores para móviles aumentando los tamaños de fuente y adaptando el tamaño del contenido para que se ajuste a la pantalla, o bien mostrando solo la parte del contenido que cabe en pantalla.
En estos casos, el tamaño de la fuente puede cambiar en función del dispositivo, por lo que es posible que, en algunos dispositivos, los usuarios tengan que tocar la pantalla dos veces o pellizcarla para ampliar el contenido y así poder verlo correctamente e interaccionar con él. Si los usuarios deben interactuar con una página de este modo en un dispositivo móvil, Google puede determinar que no está optimizada para móviles.
Como en la página de la izquierda no se incluye la metaetiqueta de viewport, cuando esta se muestra en un navegador para móviles, se asume que la anchura es la de un ordenador. En consecuencia, la página se adapta para que quepa en la pantalla, lo que hace que el contenido sea difícil de leer. A la derecha vemos la misma página con una metaetiqueta de viewport especificada que la encaja en la anchura del dispositivo. En este caso, el navegador para móviles no adapta la página y el contenido se puede leer.
Si son imágenes adaptables, incluye el elemento <picture>.
Por regla general, si el sitio web funciona en un navegador reciente, como Google Chrome o Apple Mobile Safari, debería funcionar con nuestros algoritmos.
Por qué usar el diseño adaptable
- Rendimiento y velocidad de carga extrema: Esta es su mayor ventaja. Como el servidor envía únicamente el código, las imágenes y los scripts necesarios para la versión móvil, evitas que el teléfono del usuario descargue código de escritorio innecesario. Esto impacta muy positivamente en las métricas de rendimiento (Core Web Vitals como el LCP).
- Experiencia de Usuario (UX) hiperpersonalizada: Te permite diseñar flujos de navegación completamente distintos. Por ejemplo, en móvil puedes priorizar botones táctiles grandes (touch targets), quitar barras laterales completas o cambiar la jerarquía de la información de una forma que sería muy difícil solo ocultando elementos con CSS.
- Integración con sistemas heredados (Legacy): Si tienes una web de escritorio enorme y muy compleja de rediseñar desde cero, el diseño Adaptive te permite crear una versión móvil moderna y rápida de forma paralela, sin tener que tocar o romper el código de la web de escritorio.
- Menor consumo de recursos del dispositivo: Al no usar reglas CSS complejas para reordenar todo visualmente, el navegador del dispositivo móvil del usuario tiene que hacer mucho menos esfuerzo de procesamiento (renderizado), lo que ahorra batería y mejora la respuesta al interactuar (INP).
De hecho multitud de webs actualmente utilizan esta práctica, como pueden ser: Booking, Wikipedia o el propio Google.
Conlleva más tiempo de implementación que un responsive, pero puede ayudar a generar páginas mucho más rápidas, ya que puedes prescindir de cargar CSS y elementos que no vayan a utilizarse en el dispositivo al que están destinados.
Esta configuración se puede hacer tanto desde el servidor (apache, nginx, litespeed, azure…) como desde el propio lenguaje de programación backend (php, python, java…)
Diferentes URL
Este sistema, aunque cada vez menos común, todavía lo siguen aplicando muchas webs (sobre todo proyectos antiguos que nunca migraron a responsive). Consiste en tener dos versiones completamente separadas de la web: una para escritorio en el dominio principal (ejemplo.com) y otra para móvil en un subdominio (m.ejemplo.com) o en un subdirectorio (/m/).
Consejo
Cada versión tiene su propio HTML, sus propias URLs y se sirven de forma totalmente independiente. Cuando un usuario entra desde un dispositivo móvil, el servidor lo detecta y lo redirige a la versión correspondiente (de ahí el nombre de "Publicación Dinámica" aplicado a este sistema, aunque técnicamente se diferencia de la publicación dinámica pura en que aquí cambia la URL).
A nivel SEO esta configuración es la más compleja de mantener porque tienes que coordinar dos versiones de la web a la vez. Cualquier cambio que hagas en la versión de escritorio lo tienes que replicar en la móvil. Si te despistas con una página, te puedes encontrar con que la versión móvil devuelve 404 mientras que la de escritorio funciona perfectamente, y como Google indexa mobile-first, esa página desaparece del índice.
Estas son las cosas que debes revisar si trabajas con un proyecto que tenga URLs independientes (recomendaciones oficiales de Google):
- Comprueba que el estado de error de tus páginas sea el mismo en ambas versiones. Si una página de tu sitio para ordenadores muestra contenido normal, pero el sitio móvil devuelve una página de error, la página no se incluirá en el índice.
- Asegúrate de que la versión para móviles de tu sitio no tenga URLs con fragmentos. Los fragmentos de URL son la parte que se encuentra al final de las URL y empiezan por #. La mayoría de las veces, las URL con fragmentos no se pueden indexar, por lo que no se incluirán en el índice una vez que tu dominio pase a la indexación centrada en los móviles.
- Comprueba que las páginas para ordenadores que ofrecen contenido diferente tengan una versión para móviles equivalente. Si varias URL redirigen a la misma URL de la versión para móviles (por ejemplo, la página principal), todas esas URL no se incluirán en el índice una vez que tu dominio pase a la indexación centrada en los móviles.
- Verifica las dos versiones de tu sitio en Search Console. De este modo, te aseguras de tener acceso a los datos y los mensajes de ambas versiones. Es posible que se produzca un cambio en los datos de tu sitio cuando Google empiece a indexarlo siguiendo la indexación centrada en los móviles.
- Comprueba los enlaces hreflang de distintas URL. Si has incluido elementos de enlace rel=hreflang para internacionalizar el sitio, confirma que los enlaces hreflang del sitio móvil dirigen a URLs para móviles, y que los del sitio para ordenadores llevan a URLs de la versión para ordenadores.
- Prepara tu sitio móvil para que pueda hacer frente a un posible aumento de la frecuencia de rastreo.
- Comprueba que tus directivas robots.txt funcionen del modo esperado en ambas versiones del sitio. Con un archivo robots.txt, puedes indicar qué partes de tu sitio web pueden rastrearse y cuáles no. En la mayoría de los casos, debes usar las mismas directivas robots.txt en ambas versiones de tu sitio.
- Utiliza los elementos de enlace rel=canonical y rel=alternate correctos en ambas versiones de tu sitio web.
La etiqueta clave aquí es la combinación de rel="alternate" en la versión de escritorio apuntando a la móvil, y el rel="canonical" en la versión móvil apuntando a la de escritorio. De esta forma le indicas a Google que ambas URLs son la misma página pero en diferentes formatos:
Siempre se debe apuntar con canonical a la versión Desktop pese a lo que pueda decirte la intuición con el mobile indexing first. Veamos un ejemplo de cómo debería ser en una web:
Desktop: <link rel="canonical" href="https://example.com/><link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/"><link rel="alternate" hreflang="es" href="https://example.com/es/"><link rel="alternate" hreflang="fr" href="https://example.com/fr/">Mobile:<link rel="canonical" href="https://example.com/"><link rel="alternate" hreflang="es" href="https://m.example.com/es/"><link rel="alternate" hreflang="fr" href="https://m.example.com/fr/">
Como puedes ver, las únicas metaetiquetas que pueden ser distintas son el hreflang y el alternate con onlyscreen.
Ejemplo real de una web utilizando este tipo de configuración móvil:
Bien implementadas:
Un ejemplo totalmente funcional sería Filmaffinity, donde se puede observar donde cumple a la perfección lo que se dice la documentación, incluyendo la complejidad que tiene este sistemas con la configuración de hreflangs al ser una página internacional traducida en varios idiomas.
También tendríamos la página de korea.kr, donde podemos ver esta implementación en la versión desktop:
Mientras que en la versión mobile apunta con el canonical de forma correcta a la versión desktop:
Implementación dudosa:
Youtube, poco le importará porque en casa del herrero cuchillo de palo y Youtube se tratará de forma distinta pues no sigue su documentación y el alternate de todos los vídeos va a la home:
Mal implementadas:
Alibaba, pues envía a la misma versión de URL en lugar de a una mobile distinta:
AMP
AMP (Accelerated Mobile Pages) es un framework open source que en su momento Google impulsó con mucha fuerza y que aplicaba un sistema similar al de URLs independientes: una versión de la web optimizada para móvil servida desde una URL diferente, ya sea por subdominio (amp.ejemplo.com) o por subdirectorio (/amp/).
El framework surgió en 2015 como respuesta de Google al avance de Facebook Instant Articles. La idea era ofrecer una versión ultraligera de las páginas web que cargara prácticamente al instante en dispositivos móviles, y para conseguirlo AMP imponía una serie de restricciones bastante estrictas:
- Un subconjunto limitado de HTML, con etiquetas propias como
<amp-img>,<amp-video>,<amp-iframe, etc. - Prohibición de JavaScript propio (solo se podía usar la librería JS de AMP).
- CSS inline y con un límite máximo de 75KB.
- Carga asíncrona de todos los recursos.
- Servido desde la caché de Google (cdn.ampproject.org) para acelerar todavía más la entrega.
A nivel SEO, Google le dio un trato preferencial muy claro: las páginas AMP aparecían en el carrusel de noticias destacadas (Top Stories) en los resultados móviles, y ese carrusel estaba prácticamente reservado para contenido AMP. Esto generó una corriente masiva de adopción, especialmente en medios de comunicación, que se vieron prácticamente obligados a implementar AMP si querían aparecer en esa posición tan visible.
El problema era que AMP suponía mantener una segunda versión de la web con las limitaciones que ya hemos comentado en las URLs independientes, más las restricciones propias del framework. Para muchos editores acabó siendo un dolor de cabeza: maquetar dos veces el contenido, perder control sobre el diseño, problemas de medición de analítica, dificultades para monetizar con publicidad, y la sensación de que tu contenido se servía desde un dominio de Google y no desde el tuyo.
A partir de 2021, con la actualización Page Experience, Google cambió el rumbo y dejó de exigir AMP para aparecer en Top Stories. A partir de ese momento, cualquier página que cumpliera con buenas métricas de Core Web Vitals podía optar a esa posición destacada. Esto le quitó a AMP su principal ventaja competitiva y de hecho recibió bastante alivio por parte de la comunidad SEO.
A día de hoy AMP sigue existiendo y funcionando, pero ha perdido la mayor parte del impulso que tenía. Si te encuentras con un proyecto que todavía mantiene AMP, lo más habitual es valorar su retirada midiendo el tráfico real que aporta frente al coste de mantenerlo. En la mayoría de los casos, una web responsive bien optimizada con buenas métricas de Core Web Vitals consigue los mismos (o mejores) resultados sin necesidad de mantener una versión paralela.
Si te preguntas por qué muchos medios de noticias en España han seguido utilizando AMP hasta hace poco es debido a que entre ellos se suelen fijar lo que aplica otro, y pocos se atreven a tener la iniciativa para retirarlo ya que la ventaja de “quitarse de encima AMP” cuanto ya tienen el proceso muy acostumbrado no compensa con la posible pérdida de hacer un cambio tan radical y que no de resultados.Aún muchos medios siguen utilizándolo.
Si decides mantenerlo, ten en cuenta que la relación entre la versión canónica y la versión AMP funciona de forma muy similar al sistema de URLs independientes: la página de escritorio incluye un <link rel="amphtml"> apuntando a la versión AMP, y la versión AMP incluye un <link rel="canonical"> apuntando a la versión principal.
De hecho, si bien el 14/06/2026 aún seguían funcionando los enlaces de Google con AMP, ahora a día 22/06/2026 por parte del dominio de Google ocurre esto:
A día de hoy a pesar de seguir existiendo medios que lo siguen utilizando, no parece ser lo más recomendable.
Mixto
No todo es blanco o negro y de hecho se puede hacer una configuración mixta.
Se puede tener una configuración responsive para hacer un desarrollo rápido y más económico pero añadir Adaptive para elementos concretos que puedan ser más sensibles de cara a la velocidad de la web.
Por ejemplo las imágenes o vídeos que solo van a cargar en uno de los dos dispositivos no tiene sentido ocultarlas simplemente con CSS, pues el usuario tendrá que descargar igualmente dicho elemento pudiendo afectar a su velocidad.
Para hacer esto podemos crear una función que nos permita hacer dicho condicional en cualquier web. Voy a poner el ejemplo de la función con PHP
function esDispositivoMovil() {
$userAgent = strtolower($_SERVER['HTTP_USER_AGENT']);
$patronesMoviles = '/(android|iphone|ipad|ipod|blackberry|windows phone|opera mini|opera mobi|palm|symbian|nokia|fennec|kindle|silk|playbook|bb10|meego|webos|mobile|tablet|smartphone)/i';
return preg_match($patronesMoviles, $userAgent);
}Entonces añadiendo los user-agents automáticos de la versión mobile ya podemos poner a nuestro gusto elementos que funcionen sólo en el móvil o solo en desktop a nuestra voluntad. Por ejemplo:
<?php
if (esDispositivoMovil()): ?>
<img src="/imagenes/ejemplo.webp">
<?php endif; ?>De esta manera dicha imagen solo se verá cuando se carga con la versión móvil como aparece en el vídeo.
Cómo auditar la versión móvil de una web para un mejor SEO
A continuación te guiaré paso a paso en la auditoría de la versión móvil de tu web.
Meta Viewport
En cualquiera de los casos para que una web pueda estar adaptada a móviles debe tener la metaetiqueta viewport configurada.
La etiqueta <meta name="viewport"> le dice al navegador móvil cómo debe dimensionar y escalar la página al renderizarla. Sin ella, los navegadores móviles asumen que la web está diseñada para escritorio (típicamente 980px de ancho) y la encogen para que quepa en la pantalla, dejando un resultado ilegible que obliga al usuario a hacer zoom.
Sin necesidad de profundizar mucho con esta metaetiqueta, vamos a ver los atributos básicos que puedes tener en cuenta para un proyecto desde cero o para auditar una web que ya lo tiene implementado.
width=device-width: hace que el ancho del viewport coincida con el ancho del dispositivo en píxeles CSS. Es el parámetro fundamental: sin esto, no hay diseño responsive real.initial-scale=1: Define el zoom inicial. 1 significa 1 píxel CSS = 1 píxel de dispositivo (ajustado por DPR). Sin esto, algunos navegadores aplican escalados raros al rotar el dispositivo.minimum-scale y maximum-scale: limitan cuánto puede ampliar/reducir el usuario.user-scalable=no: bloquea el zoom del usuario. Evítalo: es un problema de accesibilidad grave y los navegadores modernos (Safari iOS) lo ignoran por defecto.viewport-fit=cover: necesario en iPhones con notch/Dynamic Island si quieres que el contenido llegue hasta los bordes (combinado con env(safe-area-inset-*) en CSS).interactive-widget: controla cómo se comporta el viewport cuando aparece el teclado virtual (resizes-visual, resizes-content, overlays-content).
En cualquiera de los casos, si encuentras una web que no lo tiene con esta configuración estará correcto en la mayoría de los casos:
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover, interactive-widget=resizes-content">
Si tu web no tiene meta viewport tendrás problemas importantes de indexación y de usabilidad para el usuario.
El efecto se ve muy claro, aquí podemos ver un ejemplo de cómo se ve la web del ayuntamiento de Jumilla en junio de 2026:
Como se puede observar, se queda con un tamaño en un dispositivo móvil con el cual apenas se puede interactuar.
La meta-viewport es cierto que no lo soluciona todo y de hecho hay que hacer un trabajo de diseño a posteriori, pero en el caso de añadirle la metaviewport la página quedaría así:
Un ejemplo claro lo marca la web de aprendizaje w3school:
Scroll lateral
A menos que sea con un propósito de un slider, si se necesita mover la pantalla lateralmente para poder leer y ver el contenido es símbolo de una mala experiencia del usuario, lo que puede desembocar en problemas importantes de posicionamiento
Se suele deber a elementos que ocupan en medidas absolutas un tamaño mayor del que realmente tiene la pantalla, generando en muchas ocasiones este efecto:.
Teclado en los campos de escritura
Los campos de texto que rellenan los usuarios son críticos en la parte móvil.
El usuario en el móvil no cuenta con un teclado físico como sí ocurre con los ordenadores, por lo cual el comportamiento es totalmente diferente.
Hay que revisar con un móvil real que cuando se abre el teclado se ve suficiente de la pantalla como para que el usuario pueda quitar el teclado o ver que está escribiendo.
La frustración que supone intentar contactar y no conseguirlo hace que el SEO sea el menor de los problemas, ya que el potencial cliente puede descartarte inmediatamente tras la insatisfacción.
Navbar de la web
Hay que asegurarse de que sea fácil de navegar. No es necesario que tenga exactamente los mismos elementos de navegación que en Desktop. Sin embargo, sí que es importante que la navegación sea fluida e intuitiva.
En la barra de navegación no hay por qué poner el acceso a todas y cada una de las URLs. Lo que sí hay que hacer es asegurarse de:
- Puedes desplegar por completo la barra de navegación y llegar a cada una de los enlaces (es sorprendente la cantidad de veces que esto no se cumple).
- Debe tener un menú de hamburguesa fácil de descubrir. Es un estándar y los usuarios están acostumbrados a navegar de esa forma desde el móvil.
- Los elementos deben tener más de 48px y tener una separación entre cada elemento para no sentirse torpes a la hora de navegar
- El usuario debe poder cerrar el menú de forma fácil e intuitiva por si ha abierto el menú por error, solo quería revisar o ha cambiado de opinión.
- Evitar superponer elementos a los elementos clickables de la barra de navegación. Aunque se debe hacer siempre, aquí es aún más crítico.
Breakpoints
Se deben tener en cuenta ciertos tamaños de móviles de los dispositivos más habituales, lo que en ocasiones es un buen diseño en desktop, no es tan buena idea en móvil con la superposición de elementos, generando una situación de mala legibilidad, ya sea porque el texto es demasiado pequeño y denso o porque no hay suficiente contraste de colores.
back button hijacking
Debes asegurarte que en tu web cuando el usuario intenta retroceder pueda salir de la página de forma inmediata.
A día de hoy “secuestrar” el botón hacia atrás mostrando un pop up o impidiendo la salida directa tiene muchísimas posibilidades de ser penalizado.
Superposición de elementos clave
Puede parecer una tontería, pero en ocasiones el botón de aceptar el banner de cookies puede estar solapado por un CTA o cualquier botón que impide la correcta navegación por la web.
Puede ocurrir con multitud de elementos clave como enlaces de la barra de navegación entre otros.
Esto no solo genera una alta frustración en el usuario sino que puede afectar de forma directa en el posicionamiento.
Además este error es mucho más común de lo que pueda parecer debido a que en muchas ocasiones se diseña para ordenador o se coge una plantilla, se añaden elementos y no se le echa más allá de un breve vistazo por encima.
Lo ideal es acceder desde el móvil y simular un “Customer Journey” (Cómo si fueses un usuario que va a adquirir un producto o servicio, por donde entraría a la web y cómo terminaría de hacer su compra).
Anuncios
Se debe seguir el estándar de Better ads Standards al mostrar anuncios, de lo contrario es posible que debido al espacio que ocupen puedan afectar al posicionamiento web o sea innavegable para los propios usuarios.
En móvil la Coalition for Better Ads marca como especialmente molestos (y por tanto a evitar):
- Pop-ups que cubran el contenido tras cargar la página, sobre todo si tapan más del 30% de la pantalla.
- Prestitial ads con cuenta atrás, es decir, los que te obligan a esperar antes de ver el contenido.
- Anuncios autoplay con sonido.
- Sticky ads de gran tamaño (más del 30% del viewport) que no se pueden cerrar.
- Flashing ads y anuncios con animaciones agresivas.
- Full-screen scrollover ads, los que se interponen mientras haces scroll y obligan a desplazarte por encima para continuar leyendo.
Más allá del estándar, en términos de SEO técnico los anuncios mal implementados impactan directamente en Core Web Vitals:
- CLS: cualquier creatividad que se inyecte sin reservar espacio (sin min-height o contenedor con dimensiones definidas) va a generar layout shift. Pasa mucho con AdSense, GAM y prebid si no se configuran slots con tamaños fijos.
- INP: los wrappers de header bidding (prebid, amazon TAM, etc.) y los scripts de terceros que cargan los anuncios suelen ser uno de los principales culpables de bloquear el hilo principal en el móvil. Conviene cargarlos de forma asíncrona y retrasar la inicialización hasta el after-load.
- LCP: si el anuncio se sitúa por encima del contenido principal (above the fold) y bloquea el render, puede competir con el LCP real o convertirse él mismo en el elemento LCP.
Recuerda además que desde 2017 Google penaliza explícitamente los intersticiales intrusivos en móvil (más allá de los avisos legales obligatorios como el de cookies o verificación de edad), por lo que aunque tus anuncios cumplan Better Ads Standards, si bloquean el acceso al contenido principal en la entrada desde búsqueda puede ser problemático.
Contenido
Debe ser igual:
- Metaetiquetas (salvo la excepción contada si hay diferencia de URLs)
- Datos estructurados
- Atributos de imágenes (El texto alternativo debe ser el mismo que las imágenes que hay en común)
- Headings
- Hreflangs
Sin embargo sí que puede haber texto y contenido que si no tiene intención de ser posicionado, se puede eliminar para que la experiencia de los usuarios en móviles sea mucho más fluida.
Cuando se mantiene texto o cualquier contenido en la versión móvil tiene que ser con un motivo de que sea útil. A día de hoy no se posiciona por cantidad de texto.
Por lo que se debe tener en cuenta que el texto se debe mantener en el móvil siempre y cuando tenga sentido para entender la página. Si no es así, es un texto que sobra.
Menos es más.
Distribución de las imágenes
Los ordenadores tienden a tener pantallas horizontales, mientras que los dispositivos móviles tienen las pantallas verticales. Esto cambia el panorama muchísimo más de lo que alguien pueda pensar en primera instancia.
Mientras que en el ordenador puede tener bastante encaje poner en un lado imagen y en el otro lado texto, en el móvil, teniendo además en cuenta que son pantallas pequeñas carece de todo sentido.
Así es como se ve si no se cambia la distribución de imágenes:
En el caso de que las imágenes sean relevantes para el contenido, se deberían ver aproximadamente así:
Mostrar elementos con interacción
En el móvil no se hace hover con ningún puntero, porque el usuario hace click con sus propias manos.
Esto hace que las cajas y botones deben ser claramente intuitivos sin necesidad de efectos para que el usuario sepa que con dicho elemento se puede interactuar.
Dichos elementos deben tener como mínimo un tamaño de 48x48px y suficiente separación entre ellos.
Apple
Los usuarios de Apple suelen utilizar Safari, pero incluso cuando utilizan Chrome usan el webkit de Safari.
Para estos casos recomiendo utilizar saucelabs, browserstack o lambdatest.
Todos ellos son de pago, pero tienen versiones de prueba gratuita donde puedes comprobar el que más te guste o simplemente usar la prueba para un uso puntual
En Saucelabs por ejemplo te permite ver cómo se visualizan los elementos y sacar una consola:
De esta forma puedes revisar cómo se distribuye el HTML en este tipo de dispositivos si es que trabajas con cualquier otro sistema operativo. Ya que en ocasiones que algo se vea bien en móvil para android con Chrome no significa que en el resto también.
Reflexiones finales
A pesar de que el mobile-first indexing lleva años siendo la norma de Google, optimizar una web para dispositivos móviles sigue siendo un desafío constante que va mucho más allá de aplicar un par de reglas CSS.
Como hemos visto a lo largo de este artículo, la elección de la arquitectura técnica y el cuidado de los detalles visuales impactan directamente tanto en tu posicionamiento como en los costes de mantenimiento del proyecto.
Personalmente yo no recomendaría cambiar la arquitectura por capricho, pero sí que tendría en cuenta que hacer en caso de una migración que implique cambiar la tecnología.
Si es un proyecto ya existente y por ejemplo tiene URLs dinámicas, yo lo que haría sería adaptarlo
A modo de resumen, si te enfrentas a un desarrollo nuevo o a una auditoría SEO, recuerda estas directrices clave:
- Prioriza el equilibrio entre rendimiento y mantenimiento: El diseño Responsive es el estándar recomendado por su facilidad de gestión. Sin embargo, aplicar un enfoque Mixto (Responsive + Adaptive) es una estrategia excelente para aligerar la carga de recursos pesados y dominar las métricas de rendimiento.
- Actualiza o descarta prácticas obsoletas: Mantener URLs independientes o seguir atado a las restricciones del ecosistema AMP suele generar hoy en día más problemas de rastreo, indexación y canonicalización que ventajas reales.
- La experiencia de usuario (UX) es inseparable del SEO: Detalles que parecen puramente de diseño son críticos. Una mala usabilidad genera rebote, y el rebote anula cualquier esfuerzo de posicionamiento.
- Audita siempre en entornos reales: No te fíes únicamente de redimensionar la ventana del navegador en tu ordenador. Utiliza herramientas de emulación, revisa el comportamiento del teclado virtual y asegúrate de que el flujo de navegación es impecable en sistemas como iOS.
En definitiva, el SEO Mobile no consiste en hacer que la versión de escritorio "quepa" en un teléfono, sino en entender cómo interactúa el usuario con sus manos y ofrecer el contenido de la forma más rápida y accesible posible.
¿Tienes preguntas? Estamos en LinkedIn y en X.