SEO y Progresivo Web Apps: Mirando al Futuro – Moz

image_pdfimage_print


los Profesionales de SEO siempre han desconfiado de JavaScript.

Esto es en parte basado en la experiencia, la capacidad de los motores de búsqueda para descubrir, rastreo, y con precisión el contenido del índice que depende mucho de JavaScript ha sido históricamente baja. Pero también es habitual, nacido de una general desconfianza hacia JavaScript en todas sus formas, que no se basa en la comprensión o experiencia. Esto se manifiesta como la dependencia tradicional de las técnicas SEO que no han sido relevantes durante años, y una convicción de que para ser bueno en técnicas SEO no requiere una comprensión de moderno desarrollo de la web.

Como Mike King escribió en su post La Técnica SEO Renacimiento, estas actitudes están contribuyendo a “una creciente técnica de la brecha de conocimientos en SEO como un campo de la comercialización, lo que hace difícil para muchos SEOs para resolver nuestros problemas nuevos”. También ponen de SEO profesionales en riesgo de quedar atrás, ya que muchos de nosotros nos negamos a explorar – digamos abrazo – tecnologías, tales como la Progresiva Aplicaciones Web (PWAs), moderno frameworks de JavaScript, y otros avances que son cada vez más vistos como el futuro de la web.

En este artículo, voy a tomar una nueva mirada a la PWAs. Así como la exploración de las implicaciones para el SEO y la usabilidad, voy a estar mostrando algunos de los modernos marcos y construir herramientas que usted puede no haber oído hablar de, y sugiere formas en las que nos tenemos que adaptar, si vamos a ponernos a la vanguardia tecnológica de la web.

1. Resumen: PWAs, los SPAs y los trabajadores del servicio

Progresivo de las Aplicaciones Web son esencialmente sitios web que brindan una experiencia de usuario similar a la de una aplicación nativa. Funciones como las notificaciones push permiten una fácil re-engagement con su público, mientras que los usuarios pueden agregar sus sitios favoritos para su pantalla de inicio sin la complicación de las tiendas de aplicaciones. PWAs puede seguir funcionando sin conexión o en la baja calidad de las redes, y que permiten un nivel superior, a pantalla completa, experiencia en dispositivos móviles que es más cercana a la ofrecida por los nativos de iOS y Android.

lo Mejor de todo, PWAs hacer esto manteniendo – e incluso mejorar fundamentalmente la abiertos y accesibles a la naturaleza de la web. Como sugiere el nombre que se progresivas y sensible, diseñado para funcionar para todos los usuarios, independientemente de su elección de navegador o dispositivo. Ellos también pueden guardarse hasta la fecha de forma automática y — como veremos — son detectable y vinculables, como en sitios web tradicionales. Por último, no es de todo o nada: los sitios web pueden implementar un subconjunto limitado de estas tecnologías (uso de un simple trabajador de servicio) y empezar a cosechar los beneficios de inmediato.

La especificación es todavía bastante joven, y, naturalmente, hay áreas que necesitan trabajo, pero que no dejan de ser uno de los mayores avances en las capacidades de la web en una década. La adopción de PWAs está creciendo rápidamente, y las organizaciones están descubriendo la infinidad de negocios del mundo real metas pueden tener un impacto.

Usted puede leer más acerca de las características y requisitos de PWAs sobre los Desarrolladores de Google, pero dos de las tecnologías clave que hacen PWAs posibles son:

tenga en cuenta que estas tecnologías no son mutuamente excluyentes; la única página de la aplicación (modelo llega a la madurez con AngularJS en 2010), obviamente, es anterior a los trabajadores de los servicios y PWAs por algún tiempo. Como veremos, también es perfectamente posible crear un PWA que no está construido como una sola página de la aplicación. Para los fines de este artículo, sin embargo, nos vamos a centrar en los ‘típicos’ enfoque para el desarrollo de la moderna PWAs, la exploración de la SEO implicaciones — y oportunidades — que se enfrentan los equipos que decidan unirse al creciente número de organizaciones que hacen uso de la dos tecnologías descritas anteriormente.

vamos a empezar con la aplicación de shell de la arquitectura y la representación de las implicaciones de una sola página modelo de aplicación.

2. La aplicación de shell de la arquitectura

En pocas palabras, la aplicación de shell de la arquitectura implica agresivamente almacenamiento en caché de los recursos estáticos (el mínimo de la interfaz de usuario y funcionalidad) y, a continuación, cargar el contenido de forma dinámica, usando JavaScript. La mayoría de JavaScript moderno SPA marcos anime a algo parecido a este enfoque, y la separación de la lógica y de contenido en este modo, beneficia tanto a la velocidad y facilidad de uso. Interacciones sensación instantánea, muy parecidos a los de una aplicación nativa, y el uso de datos puede ser muy económico.

Crédito a

Como he mencionado en la introducción, una fuerte dependencia en el lado del cliente con JavaScript es un problema para el SEO. Históricamente, muchos de estos problemas se centra en el hecho de que mientras que los agentes de búsqueda requieren de Url únicas para descubrir y el índice de contenido, de una sola página de apps no es necesario cambiar la dirección URL para cada estado de la aplicación o sitio web (de ahí la frase “de una sola página”). La dependencia de los identificadores de fragmento — que no se envían como parte de una solicitud HTTP para manipular dinámicamente el contenido sin necesidad de recargar la página fue un gran dolor de cabeza para el SEO. Las soluciones heredadas suponía la sustitución de la almohadilla con un llamado hashbang (#!) y el _escaped_fragment_ parámetro, un hack que ha-ya no se utiliza y que no vamos a explorar hoy en día.

Gracias a la de HTML5 historia de la API y el método pushState, ahora tenemos una mejor solución. La URL del navegador de la barra se puede cambiar el uso de JavaScript sin necesidad de recargar la página, para así mantener en sincronización con el estado de su aplicación o sitio web y que permite al usuario hacer un uso eficaz del navegador del botón “atrás”. Mientras que esta solución no es una varita mágica — el servidor debe estar configurado para responder a las solicitudes de estas profundas Url por la carga de la aplicación correcta, en su estado inicial — no nos proporcionan las herramientas para resolver el problema de las URLs en los Balnearios.

El mayor problema al que se enfrenta el SEO hoy en día es en realidad mucho más fácil de entender: la representación de contenido, es decir, cuando y cómo se lleva a cabo.

de Representación de contenido

tenga en cuenta que cuando me refiero a la representación de aquí, me estoy refiriendo al proceso de la construcción de la HTML. Nos estamos centrando en cómo las contenido se pone en el navegador, no el proceso de elaboración de los píxeles de la pantalla.

En los primeros días de la web, las cosas eran más simples en este frente. El servidor suele devolver todo el HTML que era necesario para procesar una página. Hoy en día, sin embargo, muchos de los sitios que utilizan una sola página de la aplicación del marco de entregar sólo un mínimo de HTML desde el servidor y delegar el trabajo pesado para el cliente (ya sea un usuario o un bot). Dada la escala de la web esto requiere de mucho de tiempo y de recursos computacionales, y como Google dejó claro en su I/O conferencia en 2018, esto plantea un problema importante para los motores de búsqueda:

“La representación de JavaScript-powered, de los sitios de Búsqueda de Google es diferido hasta que el Robot de google cuenta con recursos disponibles para procesar el contenido.”

En sitios más grandes, esta segunda ola de indexación a veces puede ser retrasado por varios días. En la parte superior de esto, usted es probable encontrar una gran variedad de problemas fundamentales de la información como canónica etiquetas y metadatos que se perdió completamente. Recomiendo ver el video de Google excelente charla sobre este tema, para un resumen de algunos de los retos que enfrentan los modernos agentes de búsqueda.

Google es uno de los pocos motores de búsqueda que se hace con JavaScript. Lo que es más, lo hace mediante una web que prestan servicio que hasta hace muy poco estaba basado en Chrome 41 (lanzado en 2015). Obviamente, esto tiene implicaciones fuera de una sola página de apps, y la más amplia tema de JavaScript SEO es un área fascinante a la derecha ahora. Rachel Costello reciente libro blanco sobre JavaScript SEO es el mejor recurso que he leído sobre el tema, y que incluye aportaciones de otros expertos como Bartosz Góralewicz, Alexis Sanders, Addy Osmani, y muchos más.

Para los efectos de este artículo, la conclusión clave aquí es que en el 2019 no se puede confiar en los motores de búsqueda con precisión de rastreo y hacer que su JavaScript-dependiente de la aplicación web. Si su contenido es mostrado lado del cliente, será de uso intensivo de recursos de Google para rastrear, y su sitio será un desempeño deficiente en la búsqueda. No importa lo que has oído por el contrario, si la búsqueda orgánica es un valioso canal para su sitio web, usted necesita para hacer disposiciones para el procesamiento del lado del servidor.

Pero procesamiento del lado del servidor es un concepto que con frecuencia se malinterpreta…

“Implementar el procesamiento del lado del servidor”

Este es un común SEO recomendación de la auditoría que oigo a menudo produce alrededor como si se tratara de un auto-contenida, fácilmente-tramite de la solución. En el mejor de los casos es una simplificación de un enorme compromiso técnico, y en el peor, de un malentendido de lo que es posible/necesario o beneficioso para el sitio web en cuestión. Procesamiento del lado del servidor es un resultado de las muchas posibles configuraciones y puede lograrse de muchas maneras diferentes; en última instancia, sin embargo, estamos preocupados con conseguir nuestro servidor para volver a HTML estático.

Así que, ¿cuáles son nuestras opciones? Vamos a romper el concepto de servidor de contenido procesado un poco y explorar nuestras opciones. Estos son el alto nivel de los enfoques que Google descritos en el citado I/O conferencia:

El último es más limpio, no implica UA oler, y es de Google a largo plazo de la recomendación. También vale la pena aclarar que ‘híbrido de representación” no es una solución única — es un resultado de muchos enfoques posibles para hacer estática prerendered contenido disponible en el lado del servidor. Vamos a dividir lo que un par de maneras en que un resultado puede ser alcanzado.

Isomorfo/universal apps

Esta es una manera en que se podría lograr un ‘híbrido de representación de’ el programa de instalación. Isomorfo en el uso de aplicaciones de JavaScript que se ejecuta en el servidor y el cliente. Esto es posible gracias a la llegada de Node.js, que – entre otras muchas cosas permite a los desarrolladores escribir código que puede ejecutar en el backend como en el navegador.

Normalmente, usted va a configurar el marco de Reaccionar, Angular Universal, lo que sea) para que se ejecute en un servidor de Nodo, prerendering algunos o todo el código HTML antes de que se envíe al cliente. El servidor debe ser configurado para responder a una profunda direcciones Url de renderizado de HTML para la página correspondiente. En condiciones normales de navegadores, este es el punto en el que la aplicación del cliente va a la perfección tomar el relevo. El servidor procesado HTML estático para la vista inicial es ‘rehidratadas’ (brillante plazo) por el navegador, convirtiéndolo en una sola página de la aplicación y la ejecución de posteriores eventos de navegación con JavaScript.

se Hace bien, esta configuración puede ser fantástica, ya que ofrece los beneficios de capacidad de uso de procesamiento del lado del cliente, el SEO ventajas de procesamiento del lado del servidor, y una rápida primera pintura (incluso si el Tiempo Interactivas a menudo se ve afectada negativamente por la rehidratación como JS patadas). Por miedo simplificando la tarea, no voy a entrar en mucho más detalle aquí, pero el punto clave es que mientras isomorfo JavaScript / true procesamiento del lado del servidor puede ser una solución eficaz, es a menudo extremadamente complejo para configurar.

Así que, ¿qué otras opciones hay? Si usted no puede justificar el tiempo o el dinero de un completo isomorfo de la instalación, o si es simplemente demasiado para lo que estamos tratando de lograr, hay otras maneras que usted puede cosechar los beneficios de la única página de la aplicación el modelo y el híbrido de representación de instalación — sin sabotear su SEO?

Prerendering/JAMstack

Haber prestado el contenido disponible en el lado del servidor no significa necesariamente que el proceso de representación del sí mismo que debe suceder en el servidor. Todo lo que necesitamos es HTML renderizado para estar allí, listos para servir al cliente; el proceso de representación de sí mismo puede suceder en cualquier lugar que te gusta. Con un JAMstack enfoque, la representación de su contenido en HTML ocurre como parte de su proceso de construcción.

he escrito acerca de la JAMstack enfoque antes. Por medio de una rápida introducción, el término significa JavaScript, APIs, y formato, y describe una forma de crear sitios web complejos sin necesidad de software de servidor. El proceso de montaje de un sitio web de front-end de componentes — una tarea es un sitio tradicional podría lograr con WordPress y PHP se ejecuta como parte del proceso de compilación, mientras que la interactividad se maneja del lado del cliente con JavaScript y la Api.

Piense en ello de esta manera: todo vive en el repositorio de Git. Su contenido se almacena como texto sin formato markdown archivos (editable a través de una cabeza, CMS o de otras API basado en la solución) y su página de plantillas y de la asamblea de la lógica están escritos en Ir, JavaScript, Ruby, o en cualquier otro idioma de su sitio preferido generador pasa a utilizar. Su sitio puede ser construida en HTML estático en cualquier ordenador con el conjunto adecuado de herramientas de línea de comandos antes de es alojado en cualquier lugar. El conjunto resultante de la facilidad en la memoria caché de archivos estáticos, a menudo puede ser de forma segura alojado en un CDN para nada.

creo sinceramente sitio estático generadores – o, más bien, los principios y las tecnologías que las sustentan — son el futuro. Hay cada oportunidad que estoy equivocado acerca de esto, pero el poder y la flexibilidad de este enfoque debe ser claro para cualquiera que haya usado moderno mecanismo nacional de prevención basado en software de automatización como Trago o Webpack a su autor CSS o JavaScript. Me gustaría reto a cualquiera a que la prueba de la profunda Git integración ofrecida por el especialista webhost Netlify en un proyecto en el mundo real y todavía piensan que el JAMstack enfoque es una moda.

La importancia de un JAMstack el programa de instalación para nuestra discusión de una sola página de aplicaciones y prerendering debería ser bastante obvio. Si nuestro sitio estático generador puede montar HTML basado en plantillas escrito en el Líquido o el Manillar, ¿por qué no puedo hacer lo mismo con JavaScript?

Hay una nueva raza de sitio estático generador que hace precisamente esto. Con frecuencia alimentado por Reaccionar o Vue.js estos programas permiten a los desarrolladores a crear sitios web utilizando tecnología de punta frameworks de JavaScript y puede ser fácilmente configurado para la salida de SEO-friendly, static HTML para cada página (o ‘ruta’). Cada uno de estos archivos HTML es totalmente prestados contenido, listo para el consumo por los seres humanos y los robots, y sirve como un punto de entrada en una aplicación de cliente (es decir, una sola página de la aplicación). Esta es una perfecta ejecución de lo que Google denomina “híbrido de representación”, aunque la naturaleza exacta de la pre-proceso de representación de conjuntos es muy aparte de un isomorfo la instalación.

Un gran ejemplo es GatsbyJS, que está construido en Reaccionar y GraphQL. No voy a entrar en demasiados detalles, pero me gustaría animar a todo el mundo que lea esta lejos echa un vistazo a su página de inicio y una excelente documentación. Es un herramienta compatible con una razonable curva de aprendizaje, una comunidad activa (una característica-embalado v2.0 fue lanzado en septiembre), extensible plugin basado en la arquitectura, rica integraciones con muchos de los CMSs, y permite a los desarrolladores utilizar los modernos marcos de trabajo como Reaccionar sin sabotear su estrategia de SEO. También hay Gridsome, basado en VueJS, y Reaccionar Estática que — usted lo adivinó — utiliza Reaccionar.


a nivel de Empresa la adopción de estas plataformas que parece crecer; GatsbyJS fue utilizado por Nike para su Just Do It campaña, Airbnb para su sitio de ingeniería de airbnb.io, y Braun incluso han usado para alimentar un importante sitio de e-commerce. Finalmente, nuestros amigos en SEOmonitor utilizó el poder de su nueva página web.

Pero eso es suficiente por si solo de la página de aplicaciones y JavaScript, por ahora. Es el momento hemos explorado el segundo de los dos tecnologías clave que sustentan PWAs. Promesa te quedarás conmigo hasta el final (jaja, nerd broma), porque es el momento para explorar los Trabajadores del Servicio.

3. Los Trabajadores del servicio

Primero de todo, debo aclarar que las dos tecnologías en las que estamos explorando — Balnearios y los trabajadores del servicio — son no se excluyen mutuamente. Juntos constituyen la base misma de lo que comúnmente se refiere como un Progresivo Web App, sí, pero también es posible tener un PWA que no es un SPA. Usted también podría integrar un servicio del trabajador en un sitio web estático tradicional (es decir, sin ningún tipo de cliente del lado del contenido presentado), que es algo que creo que veremos pasar mucho más en el futuro cercano. Finalmente, los trabajadores del servicio de operar en conjunto con otras tecnologías como la Web de Manifiesto de la Aplicación, algo que mi colega Maria recientemente se examinan en más detalle en su excelente guía para PWAs y SEO.

en última instancia, sin embargo, es el servicio a los trabajadores que hacen de las características más interesantes de PWAs posible. Son uno de los cambios más significativos en la web de la plataforma en su historia, y todos aquellos cuyo trabajo consiste en la construcción, el mantenimiento o la revisión de un sitio web necesita para ser conscientes de este nuevo conjunto de potentes tecnologías. Si, como yo, ha sido ansiosamente la comprobación de Jake Archibald Es el Trabajador de Servicio Listo de la página para el último par de años y ver como la adopción por parte de los fabricantes de los navegadores ha crecido, sabrás que el tiempo para iniciar la construcción con el servicio de los trabajadores es ahora.

vamos a explorar lo que son, lo que pueden hacer, cómo llevarlas a la práctica, y las repercusiones para el SEO.

¿Qué puede dar servicio a los trabajadores a hacer?

Un trabajador de servicio es un tipo especial de archivo JavaScript que se ejecuta fuera de la principal del navegador hilo. Se encuentra entre el navegador y la red, y sus poderes incluyen:

Los beneficios de estos tipos de características que van más allá de la obvia la usabilidad de las gratificaciones. Así como impulsando la adopción de HTTPS a través de la web (todos los principales navegadores sólo servicio de registro de trabajadores en el protocolo seguro), trabajadores de servicios son transformadora cuando se trata de la velocidad y el rendimiento. Ellos sostienen que los nuevos enfoques e ideas como la de Google PRPL Patrón, ya que se puede maximizar el almacenamiento en caché de la eficiencia y minimizar la dependencia de la red. De esta manera, los trabajadores del servicio jugará un papel clave en hacer que la web sea rápida y accesible para los próximos mil millones de usuarios de la web.

Así que sí, son un powerhouse absoluto.

la Implementación de un trabajador de servicio

en Lugar de hacer un mal trabajo de escribir un tutorial básico aquí, estoy en lugar de ir a enlace a algunos de los principales recursos. Después de todo, usted está en la mejor posición para conocer la profundidad de su comprensión de servicio de los trabajadores debe ser.

El MDN Docs son un buen lugar para aprender más acerca de servicio de los trabajadores y de sus capacidades. Si ya estás seguro de los fundamentos del desarrollo web y disfrutar de un aprender-haciendo enfoque, recomiendo a completar Google PWA curso de formación. Se incluye todo un ejercicio práctico en servicio de los trabajadores, que es una gran manera de familiarizarse con los conceptos básicos. Si ES6 y las promesas no son todavía una parte de su JavaScript repertorio, se preparan para un bautismo de fuego.

Se lo clave para entender — y en el que te das cuenta de que muy rápidamente una vez que comience a experimentar — es que los trabajadores del servicio de mano de más de un increíble nivel de control para los desarrolladores. A diferencia de los intentos anteriores para solucionar la conectividad acertijo (tales como el malogrado AppCache), trabajadores de los servicios de no cumplir cualquiera de los patrones específicos de su trabajo; son un conjunto de herramientas para que usted escriba sus propias soluciones a los problemas que estamos enfrentando.

Una consecuencia de esto es que pueden ser muy complejas. El registro y la instalación de un trabajador de servicio no es un ejercicio simple, y cualquier intento de improvisar una por copiar-pegar de StackExchange están condenados al fracaso (en serio, no hagas esto). que no Hay tal cosa como un ready-made, el trabajador de servicio para su sitio — si eres autor de un trabajador apropiado, usted necesita entender la infraestructura, la arquitectura, y los patrones de uso de su sitio web. El tío Ben, nunca la web, el gurú de desarrollo, lo dijo mejor: con un gran poder viene una gran responsabilidad.

Una última cosa: probablemente usted se sorprenderá de cómo muchos de los sitios que usted visita ya están utilizando un trabajador de servicio. De la cabeza a chrome://serviceworker-internals/ en Chrome o acerca de:depuración de#trabajadores en Firefox para ver una lista.

Servicio de los trabajadores y SEO

En términos de SEO implicaciones, lo más relevante acerca de servicio de los trabajadores es, probablemente, su capacidad para apropiarse de las solicitudes y modificar o fabricar respuestas mediante la Captura de la API. Lo que se ve en ‘Ver código Fuente’, e incluso en la ficha Red no es necesariamente una representación de lo que fue devuelto por el servidor. Podría ser una respuesta en caché o algo construido por el servicio trabajador de una variedad de fuentes diferentes.

he Aquí un ejemplo práctico:

contenido, a la derecha? Sólo algunas secuencias de comandos en línea y los estilos y vacío de los elementos HTML — un clásico de JavaScript del lado cliente de la aplicación construida en Reaccionar. Incluso si usted abra la ficha Red y actualizar la página, la vista previa y la Respuesta pestañas se cuentan la misma historia. El contenido real sólo aparece en el Elemento inspector, porque el DOM está montada con JavaScript.

Ahora ejecuta una solicitud curl para la misma URL (https://www.gatsbyjs.org/docs/), o ir a buscar la página a través de Screaming Frog. Todo el contenido es no, junto con la debida etiquetas de título, canonicals, y todo lo demás que se puede esperar de una página mostrada en el lado del servidor. Esto es lo que un rastreador como Googlebot va a ver demasiado.

Esto es debido a que el sitio web utiliza híbrido de representación y un trabajador de servicio — instalado en su navegador — es el manejo de los posteriores eventos de navegación. No hay necesidad de buscar el HTML sin formato para la documentación de la página desde el servidor debido a la aplicación por parte del cliente ya está en funcionamiento, por lo tanto, de la Vista de Origen de muestra de lo que el el trabajador de servicio devuelve a la aplicación, no lo que la red devuelto. Además, estas páginas pueden ser recarga mientras usted está fuera de línea, gracias al trabajo de servicio de la efectividad del uso de la caché.

Usted puede detectar fácilmente que las respuestas de las que el trabajador de servicio utilizando la ficha network (Red) — nota de la ‘desde ServiceWorker’ línea de abajo.

En la ficha Aplicación, usted puede ver el trabajo del servicio que se ejecuta en la página actual junto con las diferentes cachés que ha creado. Usted puede desactivar o eludir el trabajador y prueba alguna de las funcionalidades más avanzadas que podría estar utilizando. Aprender cómo utilizar estas herramientas es un muy valioso ejercicio; no voy a entrar en detalles aquí, pero me gustaría recomendar el estudio de la Web de Google Fundamentos tutorial sobre el servicio de depuración de los trabajadores.

he hecho un esfuerzo consciente para mantener los fragmentos de código a un mínimo en este artículo, pero me conceda este. He puesto un ejemplo que ilustra cómo un simple trabajador de servicio puede utilizar la recuperación de la API para la tramitación de solicitudes y el grado de control que estamos concedida:

El resultado:

espero que este (enormemente simplificado y no de producción listo) ejemplo ilustra un punto clave, a saber, que tenemos muy granular de control sobre cómo los recursos que se manejan las solicitudes. En el ejemplo anterior, hemos optado por un simple try-cache-en primer lugar, la caída-de nuevo-a-red, la caída-de nuevo-a-custom-página patrón, pero las posibilidades son infinitas. Los desarrolladores son libres para dictar cómo deben atender las solicitudes basadas en nombres de host, directorios, tipos de archivo, métodos de petición, caché de frescura, y un montón más. Respuestas – incluyendo páginas completas, pueden ser fabricados por el trabajador de servicio. Jake Archibald explora algunos de los métodos y enfoques en su libro de cocina sin conexión.

El tiempo para aprender acerca de las capacidades de servicio de los trabajadores es ahora. El conjunto de habilidades necesarias para la moderna técnica de SEO tiene un buen grado de solapamiento con la de un desarrollador web, y hoy en día, un la comprensión profunda de las dev tools en todos los principales navegadores – incluyendo trabajador del servicio de depuración -, debe ser considerado como un requisito previo.

4. El ajuste de

Seo necesidad de adaptar

Hasta hace poco, ha sido muy fácil salirse con la no comprensión de las consecuencias y oportunidades que plantea el PWAs y servicio de los trabajadores.

Estos fueron características de vanguardia que se sentó en la periferia de lo que era relevante para el marketing en buscadores, y la ya mencionada desconfianza de muchos SEOs hacia JavaScript no hizo nada para promover la experimentación. Pero PWAs rápidamente en su camino de convertirse en una norma, y pronto será imposible hacer un trabajo eficaz sin entender la mecánica de la cómo en la que funcionan. Para permanecer relevante como una técnica de SEO (o SEO Ingeniero, para usar otro término de Mike King), debe ponerse a la vanguardia de estos tipos de cambio de paradigma de los acontecimientos. La técnica de SEO que es analfabeta en el desarrollo web es ya un anacronismo, y creo que la mayor diferencia entre la técnica y dirigida por el contenido de los aspectos de marketing de búsqueda no es mala cosa. Se especializan!

Al enterarse de que un equipo de desarrollo es la adopción de un nuevo framework JavaScript para un nuevo sitio de construcción, no es raro que los SEOs para reaccionar con un grado de cinismo. Sin duda me siento culpable de bromear acerca de los desarrolladores de ser atraídos a la última brillante tecnología o marco, y en cómo rápidamente el mundo de JavaScript, el desarrollo parece evolucionar, capa sobre capa de abstracción y la automatización de ser agregado a lo que — desde el exterior — que a menudo parece ser una torre inclinada de una pila de desarrollo. Pero vale la pena tomarse el tiempo para entender ¿por qué marcos son los elegidos, cuando es probable que las tecnologías para comenzar a ser utilizados en la producción, y cómo estas decisiones tendrán un impacto en el SEO.

en Lugar de criticar 404 manipulación o enlaces internos de una sola página de la aplicación del marco, por ejemplo, sería mucho mejor para poder ofrecer recomendaciones significativas, que han de basarse en una comprensión de cómo funcionan realmente. Como Jono Alderson observado en su charla sobre la Democratización de la SEO, las contribuciones a los proyectos de código abierto son más valiosos en la difusión de apreciación y conocimiento de SEO que en repetidas ocasiones la fijación de los mismos problemas sobre una base ad-hoc.

más Allá de SEO

Una última cosa que me gustaría mencionar: PWAs son un transformador conjunto de tecnologías que, obviamente, tiene consecuencias que van mucho más allá de la SEO. Otras áreas del marketing digital están directamente afectado demasiado, y desde mi punto de vista, uno de los más interesantes es google analytics.

Si su sitio web está parcial o totalmente funcional, mientras que fuera de línea, tiene que adaptar su configuración de analytics para dar cuenta de esto? Si suscripciones de notificación de inserción son un KPI para su sitio web, se le de seguimiento de esta meta? Recordar que el servicio de los trabajadores no tienen acceso a la Ventana de objetos, seguimiento de estos eventos no es posible con ‘normal’ código de seguimiento. En su lugar, es necesario configurar su trabajador de servicio para construir hits mediante el Protocolo de Medición, la cola si es necesario, y los envía directamente a los servidores de Google Analytics.

Esta es un área fascinante que he estado investigando mucho últimamente, y se puede leer el primer post de mi serie de artículos sobre la PWA analytics sobre el Builtvisible blog.

Eso es todo de mí, ahora! Gracias por la lectura. Si usted tiene alguna pregunta o comentario, por favor dejar un mensaje abajo o enviame un en Twitter @tomcbennet.

Muchas gracias y por sus comentarios al borrador inicial de este artículo.

This content was originally published here.

Dejá un comentario