SEO Técnico y JavaScript

¡Hola y bienvenidos a todos ustedes! Estoy muy emocionado de hablar sobre SEO técnico a todos ustedes hoy. Específicamente, quiero centrarme un poco en Vue.js, pero básicamente ninguno de los temas de los que hablaré son muy, muy específicos de Vue. Si quieres aprender más sobre SEO específico de Vue, te mostraré algunos recursos después de la charla.

Entonces, cuando hablamos de SEO, muchas personas se preguntan, ¿qué significa realmente? Además del significado obvio que es la optimización de motores de búsqueda, parece que para muchas personas no es obvio qué es esto y muchas personas piensan que es básicamente un engaño y que intenta vender enlaces y cosas así. No es eso. Fundamentalmente, lo que se trata el SEO es asegurarse de que lo que estás creando, lo que estás poniendo en línea, sea realmente visible para las personas que lo buscan, ¿verdad? Porque si estás buscando algo que aún no conoces, entonces vas a tu motor de búsqueda preferido y buscas lo que necesitas y encuentras aplicaciones web o sitios web potenciales que sirven ese propósito específico. Para hacerlo, debes asegurarte de que los motores de búsqueda realmente puedan encontrar tus cosas y, por lo tanto, las personas que usan los motores de búsqueda puedan encontrar las cosas que construiste. Y eso implica asegurarse de que los robots, que son los motores de búsqueda, porque son programas de computadora que consumen tu contenido. Debes asegurarte de que estos robots realmente puedan procesar y comprender lo que estás publicando en la web. Y para eso, hay muchas cosas que deben hacerse y muchas de ellas son técnicas, pero no todas son técnicas.

Entonces, el SEO es un campo muy amplio, similar a cómo la ingeniería de software es un campo muy amplio. Puedes hacer frontend, puedes hacer backend, puedes hacer sistemas integrados, puedes hacer desarrollo de juegos. El SEO no es solo técnico, pero hoy nos enfocaremos en el aspecto técnico, ya que todos somos desarrolladores.

En cuanto a los motores de búsqueda, los motores de búsqueda ejecutan fundamentalmente un proceso y este proceso se puede descomponer en varios pasos. El primer paso es hacer solicitudes HTTP a tu servidor, a una URL que encontramos en algún lugar, y luego obtener lo que devuelve tu servidor. Luego debemos comprender qué es. ¿Es este un sitio web sobre perros? ¿Es este un sitio web sobre gatos? ¿Es este un sitio web sobre barcos? Luego lo pondríamos en una base de datos, que se llama el índice. Y cuando alguien busca, digamos que creamos un sitio web de gatos, si alguien busca imágenes de gatos, tenemos muchos sitios web de imágenes de gatos en nuestro índice y necesitaremos obtenerlos. Y necesitamos averiguar cuál es el mejor resultado para este usuario en este momento. Y ese es el proceso de clasificación donde determinamos dónde se ubica cada uno de los sitios web en nuestro índice en la lista de resultados y luego mostramos estos resultados a los usuarios. Ahora, como desarrolladores, en realidad tenemos un impacto fundamental en este proceso porque, si lo piensas, tanto el lado del servidor como el lado del cliente influyen en si un sitio web o una aplicación web pueden ser rastreados e indexados. Si no podemos hacer solicitudes a ciertos fragmentos de contenido o si la URL nos devuelve un error 404 o un error 500, entonces no podemos realmente procesarlo más. Si lo hacemos, pero luego hay algo en JavaScript que nos impide ver cualquier contenido, entonces realmente no sabemos de qué se trata el sitio web y tampoco podemos ponerlo en el índice. Y si no está en el índice, no podemos clasificarlo realmente. Muchas personas se centran en la clasificación cuando se trata de SEO y no creo que eso sea razonable porque hay muchos factores. Y la clasificación también se ve influenciada por dónde se encuentra nuestro usuario, cuántos otros competidores hay, qué están haciendo los competidores. Entonces hay un flujo constante en las clasificaciones y no creo que tenga sentido investigar demasiado en eso. Me enfocaría más en el rastreo y la indexación, porque ahí es donde puedes tener un gran impacto. Ahora, como dije, el proceso comienza con el rastreo, lo que significa que descubrimos una URL en algún lugar y luego hacemos una solicitud a esa URL. Las URL adoptan muchas formas, pero estas son las URL típicas que probablemente hayas encontrado tú mismo o hayas proporcionado tú mismo.

Entonces tienes un host, tienes una ruta y a veces tienes subsecciones. El problema con estos hashes, o fragmentos como se les llama técnicamente, es que no están destinados a abordar contenido diferente. Una página debería tener mucho contenido y luego parte de ese contenido es el que se aborda mediante una subsección. Pero no es que si tengo una página y luego cambio el fragmento obtenga completamente un contenido nuevo que no habría visto antes si hubiera ido a /página.

Desafortunadamente, eso es lo que mucha gente está haciendo. Están utilizando enrutamiento basado en hash, lo cual es legítimo porque es mucho más fácil de configurar para un servidor de desarrollo local. Pero, no obstante, para fines de SEO, esto no es ideal porque un rastreador asume que estas dos páginas son iguales a la página de inicio, ¿verdad? El hash sobre debería ser solo una parte de lo que ya está en la página de inicio en /. Lo mismo ocurre con un signo de exclamación. Tenemos un esquema de rastreo de URL específico para este tipo de URL, pero lo hemos desaprobado porque encontramos que no funciona muy bien. Así que asegúrate de utilizar la API de Historial en lugar del enrutamiento basado en hash. En 2019, el 12% de los sitios web que rastreamos para el documento de Web Armor, desafortunadamente, siguen utilizando URL fragmentadas. Otra cosa de la que la gente se preocupa es si el renderizado del lado del cliente está bien. Y a eso digo que sí, porque tenemos una cola de renderizado y renderizamos sitios web por lo que el renderizado del lado del cliente funciona. Además, la gente dice, oh, pero lleva mucho tiempo que Google renderice realmente del lado del cliente. Eso no es cierto. El tiempo de cola es realmente muy corto. Ha sido así desde al menos 2020. Además, estamos utilizando un Chrome siempre actualizado. Entonces, si estás utilizando ES6 o algo así, no hay problema porque estamos actualizando nuestro renderizador para que sea la última versión de Chromium de todos modos. Otra cosa que suele ocurrir en aplicaciones renderizadas del lado del cliente son errores suaves. Ocurren porque vas a una URL que no existe y ves un mensaje de error y te quedas contento. Pero si verificas, en realidad ves que el estado HTTP que se devuelve es una solicitud exitosa. Y luego se realiza una solicitud a una API. Y solo si la solicitud a la API devuelve un error, mostramos una página de error. Desafortunadamente, eso no es muy bueno. Sería mejor redirigir a una URL que realmente nos dé un error del lado del servidor. Eso evitaría esos errores suaves de 404 que podrían aparecer de manera desagradable en los resultados de búsqueda. Entonces, teniendo eso en cuenta, has visto algunas cosas en las que ya puedes investigar. Y los dos problemas más grandes son no utilizar URLs adecuadas para tus rutas y también asegurarte de utilizar correctamente los servicios HTTP o mitigar los errores de 404 del lado del cliente, como se muestra aquí. Hay mucho más que considerar si estás interesado, echa un vistazo a estos recursos. Tienen mucho más contenido y mucho más tiempo para presentártelo. Y con eso, me gustaría decir muchas gracias y disfruta el resto de las Charlas Relámpago.