Cambio de paradigma, de HTML a Javascript, de desktop a mobile

1. Seo técnico
del mito al dato

2. Soy Lino Uruñuela
SeoOnTheBeach 2018
Me puedes encontrar en
@errioxa
info@funnelpunk.com
www.mecagoenlos.com
Hola!

3. Seo Técnico
¿A qué nos enfrentamos?

4. Cambio de paradigma
Del desktop al móvil
Del html al javas script
1

5. Place your screenshot here
Desktop web
Estamos
acostumbrados al SEO
para versiones desktop.
Meter alguna imagen

6. Place your screenshot here
Mobile First Index
Pero aún no pensamos
en móvil.
Meter alguna imagen

7. La teoría básica
Ya deberíamos saberla de memoria, pero vamos a
repasar algunas cosas

8. Place your screenshot here
Configuración de versiones
◉ URLs independientes
◉ Dynamic Serving
◉ Responsive Design

9. URLs independientes, características
◉ URLs distintas para cada versión
✓ Código HTML diferente.

10. ◉ Diluímos el Page Rank
◉ Google tendrá que rastrear el doble de urls
◉ Se complica la implementación de metas
URLs independientes, pros y contras

11. ✓ Podemos servir el HTML adecuado al dispositivo
✓ ¿Más facilidad para IT?
URLs independientes, pros y contras

12. ✓ Código HTML diferente
✓ Comparten URLs para ambas versiones
Dynamic Serving, características

13. ◉ Posible riesgo al implementarlo
◉ Incertidumbre / duda
✓ Menos URLs a rastrear.
Dynamic Serving, pros y contras

14. Responsive design, características
◉ Idéntico HTML
✓ La misma URL para ambas versiones.

15. Responsive design, pros y contras
◉ HTML innecesario.
◉ Carga de CSS y JavaScript innecesarios
✓ Menos URLs a rastrear.

16. El primer problema serio
Hay menos espacio

17. Place your screenshot here
Ya seas creativo, SEO o alguien
con un capricho, en las versiones
desktop cabe todo……
Definimos “visibles” los elementos
que se ven sin interacción del
usuario, a parte del scroll.
En desktop tenemos hueco para todo
ContenidoSEO
UX
SEO
SEOUX / brand UX
SEO

18. Place your screenshot here
En móvil no hay espacio
CONTENIDO
NAVEGACIÓNN
A
V
E
G
A
C
I
Ó
N
En el móvil si seguimos la misma
regla los elementos visibles a
simple vista son excasos,
¿demasiado? .
Para Google valorar solo lo visible
quizás tampoco sea suficiente,
pero no lo sabremos.

19. Place your screenshot here
Se necesitan 4 o 5 móviles para
tener el mismo espacio que en el
ordenador……
¡Lo echamos de menos!
En móvil no hay espacio
Plac
e
your
scre
ensh
ot
here
Plac
e
your
scre
ensh
ot
here
Plac
e
your
scre
ensh
ot
here
Plac
e
your
scre
ensh
ot
here
Plac
e
your
scre
ensh
ot
here

20. Con menos espacio
Prioridades
1

21. Place your screenshot here
◉ Enlaces a urls potenciales
◉ Evita enlaces innecesarios
◉ Vigila el primer enlace
◉ Schema: no visible y “legal”
◉ OjO con la carga de Js
Debemos priorizar
CONTENIDO
NAVEGACIÓNN
A
V
E
G
A
C
I
Ó
N

22. Place your screenshot here
◉ Contenidos
◉ Carga de recursos css js
◉ Orden de los recursos
◉ Otimizar imágenes
◉ Img lazy load <noscript>
Debemos priorizar
CONTENIDO
NAVEGACIÓNN
A
V
E
G
A
C
I
Ó
N

23. El contenido y JavaScript
Con la llegada de Mobile First
Index, Google se basará en el
contenido que permanece
2

24. Place your screenshot here
Google confirmó hace
poco que indexa el
contenido en dos oleadas,
pero lo lleva haciéndo
mucho tiempo
Lo hace tanto en desktop como Mobile

25. ¿Qué indexa Google? - Experimento JS
Palabra 1 Palabra 2 Palabra 3
Por defecto 1 - 5 Segundos 5 - 10 Segundos
Palabra 4
Más de 10 Segundos
Lanzamos carga de contenido en el onready y ofuscado tras...

26. Html inicial con una palabra inventada

27. Al cabo de enre 1 y 5 segundos la cambiamos

28. Lo hace tanto en desktop como
Mobile

29. Pasados más de 10 segundos nos inventamos
una tercera palabra

30. La única palabra indexada es la última

31. Google indexa lo que permanece
Palabra 1 Palabra 2 Palabra 3
1 Segundo 1 - 5 Segundos 5 - 10 Segundos
Palabra 4
Más de 10 Segundos

32. ¿Cómo podemos saber si
carga lo que queremos?
Aun estamos un poco verdes….
Tendremos que ir aprendiendo.
1

33. La prueba de optimización móvil,
no es exactamente lo que indexará

34. “
Google interpretará Java Script que se
lance sin interacción del usuario. Y el
contenido que permanece en el DOM
será el que indexe.

35. Segundo problema serio
Crawl budget, para Google rastrear el contenido, y
además, renderizarlo es mucho más costoso,

36. Place your
screenshot here
◉ Acceder a la url
◉ Descargar HTML + css js..
◉ Esperar al DOM onload
◉ Ejecutar Java Script
Renderizar cuesta más
CONTENIDO
NAVEGACIÓ
N
N
A
V
E
G
A
C
I
Ó
N

37. ¿Cuánto cuesta renderizar?
Indexar de esta manera el contenido es mucho
más costoso, y es uno de los mayores problemas
de Google en esta NUEVA ERA

38. PwMetrics
Obteniendo datos de Lighthouse
1

39. PwMertics nos da datos de cuánto tarda
el conenido en pintarse y cuándo el
usuario puede interactuar con él.

40. Y lo podemos guardar
en Google Drive

41. Y tenemos gráfica de
manera sencilla

42. 512 URLs
Sacadas previamente de Screaming
2,8 urls / minuto
Una barbaridad
3 horas
En un Dell XPS 13, I7 16 GB RAM, SSD

43. Screaming Frog
¿Cuánto tarda en crawlear un
site pequeño?
2

45. Screaming Frog Ajax
¿Cuánto tarda en crawlear un
site pequeño renderizando?
3

47. “
Google lo hará muchísimo mejor, pero
OjO, lleva mucho tiempo insistiendo
en el tiempo de carga… será por algo.

48. La segunda ola de indexación
Algo que deberemos aprender a controlar será la segunda ola de
indexación para aquellas webs que carguen contenido relevante
via java script.

49. “
“The rendering of JS powered websites
in Google Search is deferred until
Googlebot has resources available to
process” .. John Mueller

51. ◉ Google rastrea como siempre, quedándose con
el HTML sin Java Script
◉ Pasado X tiempo volverá a pasar
◉ Renderizará el contenido, y será ese HTML el
que acabe indexando, sustituyendo al que había
(si lo sustituimos)
Segunda oleada de rastreo

52. Segunda ola de inexación
¿Cómo podemos saber cuándo
se produce?
1

55. ◉ User Agent contiene Googlebot
◉ Lleva referer, la url que está renderizando
◉ Solicita recursos css, js, etc, cómo un navegador
“normal”
Identificar la segunda oleada de
rastreo

56. ¿Todavía piensas que el crawl
budget no es importante?

57. ¿Cuán de importante es el
crawl budget?
El problema del número
4

58. m = número total de distintos valores 100+9+90+2+3
n = número de agrupaciones (filtros) 5
5 filtros
Ciudad (100), marca (9), modelo (90), particular o concesionario (2), color (3)

59. 5 filtros
2.802.350.040 urls
Una barbaridad
204!÷(5!((204−5)!)) = 2.802.350.040 URLs
Ciudad (100), marca (9), modelo (90), particular o concesionario (2), color (3)

60. ¿Cómo mejorar el crawl budget?
Controlar la indexación, prescindir de lo prescindible

61. ◉ NoIndex (directiva)
◉ Canonical (señal o sugerencia)
◉ Robots.txt (directiva)
Controlar la indexación

62. El meta noindex
¿Evita el rastreo? ¿nos hace dormir mejor?
1

63. El meta noindex no evita el rastreo

64. El meta noindex impide el tráfico orgánico

65. El meta canonical
¿Evita el rastreo? ¿nos hace dormir mejor?
2

66. El meta noindex no evita el rastreoEl meta noindex no evita el rastreo

67. El robots.txt
¿Evita el rastreo?
3

68. El robots.txt sí evita el rastreo

69. Google cuenta esas urls como indexadas, por lo tanto,
¿antes no lo estaban o indexa otras?

70. ¿Alguna pregunta?
Me puedes encontrar en
◉ @errioxa
◉ info@funnelpunk.com
◉ www.mecagoenlos.com
Gracias!