La página de ayuda de Squarespace dice que el código que se ingresa en su campo de inyección del encabezado se coloca en el elemento head "en todas las páginas de su sitio".1 La página de ayuda de Ghost dice que los scripts agregados al Site Header "aparecerán en todas y cada una de las páginas de su sitio".2 La página de Webflow dice que el código de la sección Head code "se aplica a todo su sitio".3 Cada proveedor responde en una oración la pregunta que un editor hace primero: dónde va un script para que se ejecute en todas partes. WordPress responde la misma pregunta en dos lugares, porque un tema de WordPress puede construirse con bloques o con código.
Cada plataforma alojada limita el campo para todo el sitio según el plan, no según la habilidad
En Squarespace, el campo es el cuadro del encabezado del panel Code Injection.1 La misma página dice que la inyección de código "está disponible en los planes Core, Plus, Advanced y en algunos planes de facturación heredados".1 Ghost tiene su versión en Settings, luego Advanced, luego Code Injection, con un cuadro Site Header para el head y un cuadro Site Footer para el final del body.2 Webflow tiene la suya en la pestaña Custom code de Site settings, con las secciones Head code y Footer code de hasta 50,000 caracteres cada una.3 La página de Webflow añade que el código personalizado requiere un Workspace Core, Growth, Agency o Freelancer, o un sitio con un plan Site activo.3
El obstáculo en una plataforma alojada, cuando lo hay, es el plan de facturación y no el código. Un editor con un plan que incluye el campo puede pegar un elemento script sin abrir ninguna plantilla. Un editor con un plan que lo excluye no puede.
WordPress documenta dos lugares, y el rol de la cuenta decide si el primero funciona
La propia documentación de WordPress describe el Editor del sitio como la herramienta para diseñar "todo el sitio, incluidos el encabezado, el pie de página y todo lo que hay entre ellos, con bloques".4 La misma página dice que el Editor del sitio solo está disponible cuando hay un tema de bloques activo, y define una parte de plantilla como un bloque "para gestionar las áreas globales repetidas del sitio".4 Un bloque HTML personalizado colocado en la parte de plantilla del pie de página aparece dondequiera que se use esa parte. El bloque en sí se agrega desde el insertador de bloques, o escribiendo /html en un nuevo bloque de párrafo.5
La página de HTML personalizado incluye un detalle que decide si el script pegado se conserva. A partir de WordPress 7.0, el bloque tiene paneles separados para HTML, CSS y JavaScript, y los paneles de CSS y JavaScript "solo están disponibles para los usuarios con la capacidad unfiltered_html".5 Para un usuario que no la tiene (el ejemplo de la página es un Colaborador), WordPress limpia el bloque con wp_kses y elimina las etiquetas no permitidas, entre ellas la etiqueta script.5 Por lo tanto, el rol de la cuenta que pega el código forma parte de la configuración.
El propio código de un tema es el otro lugar. El Theme Handbook dice que los temas y los plugins deben cargar los scripts "usando el método estándar de WordPress": una función de puesta en cola que se llama en la acción wp_enqueue_scripts.6 La misma página muestra una clave 'strategy' => 'defer' en los argumentos de la función, que carga el script de forma diferida, con una opción 'async' al lado.6 Hay un plugin de AdBubbles para WordPress previsto; hasta que exista, estos dos lugares son los que documenta WordPress.
Cómo se carga el script importa más que el campo que lo contiene
El estándar HTML describe tres comportamientos para un elemento script clásico. Un script que no tiene ni el atributo defer ni el atributo async, en palabras del estándar, "se obtiene y se evalúa inmediatamente, bloqueando el análisis hasta que ambas cosas se completan".7 Con defer, el script "se obtendrá en paralelo y se evaluará cuando la página haya terminado de analizarse".7 Un script async se obtiene en paralelo y "se evalúa en cuanto está disponible (posiblemente antes de que termine el análisis)".7 El campo decide dónde encuentra el navegador el elemento; el atributo decide qué hace el navegador allí.
El script incrustado, adbubbles.js, es un único archivo estático, escrito en JavaScript simple sin dependencias, servido a través de la caché de Cloudflare, y se carga cuando el DOM de la página está listo. Abrir una cuenta de editor no cuesta nada, y el script incrustado tampoco. Un editor que ha agregado un sitio puede solicitar un rastreo que muestra cuáles de sus palabras se pueden vender en este momento antes de pegar nada. La página de instalación da el elemento script exacto que hay que pegar.
El alcance es la decisión que requiere reflexión
Con el script en todas las páginas, queda una decisión que ninguna página de ayuda de un proveedor puede tomar. El alcance es la parte de una página que el script incrustado puede examinar, por ejemplo el elemento article o el contenedor entry-content. Incluso dentro del alcance, el script incrustado no toca los encabezados, los enlaces, el código, el texto preformateado, los controles de formulario, la navegación, el encabezado ni el pie de página, ni nada que el editor marque con data-noads. Subraya la primera aparición de cada palabra comprada. El límite es una burbuja por palabra, y nunca hay dos en un mismo párrafo.
Supongamos que un tema de WordPress envuelve cada entrada en un contenedor con la clase entry-content y muestra una breve biografía del autor en una barra lateral. Un alcance de entry-content significa que la biografía nunca se examina, aunque esté en la página y pueda contener palabras compradas. Un alcance de todo el elemento main significa que la biografía también se examina, y una burbuja puede abrirse allí en lugar de en el artículo. Ninguna de las dos opciones es incorrecta, pero venden palabras distintas.
Además del alcance, la cuenta guarda el máximo de burbujas por página, las categorías de anunciantes que se excluyen y la verificación del sitio. La verificación adopta una de tres formas: un registro DNS TXT, una metaetiqueta o un archivo subido. La página de Ghost menciona las metaetiquetas entre los usos de su campo Site Header, así que el campo que contiene el script también contiene la etiqueta.2 Un editor que controla el DNS puede agregar el registro en su lugar.
El enlace de la burbuja está identificado para los buscadores, y no se rastrea al lector
Cada enlace dentro de una burbuja lleva rel="sponsored noopener". Google Search Central indica marcar "los enlaces que son anuncios o ubicaciones pagadas" con el valor sponsored, y permite varios valores rel en una lista separada por espacios.8 El editor no agrega nada, porque el script incrustado muestra el enlace con el atributo ya colocado. La burbuja se muestra dentro de un Shadow DOM, así que el CSS del sitio y el de la burbuja no pueden afectarse entre sí.
Lo que sale de la página son tres balizas: una de visualización por carga de página, una de apertura cuando una burbuja ha permanecido visible durante un segundo y una de clic cuando se sigue un enlace. AdBubbles no coloca cookies, no guarda identificadores y no recopila datos personales de los lectores. La coincidencia se da entre las palabras de la página y un anunciante que las compró. No elegimos qué lectores ven una burbuja, no seguimos a un lector de una página o un sitio a otro y no prometemos ningún resultado.
La conclusión práctica para un sitio con varias plantillas es la diferencia entre un campo para todo el sitio y uno para una página. Squarespace, Ghost y Webflow nombran cada uno un campo que llega a todas las páginas, y Webflow también ofrece un campo cuyo código "solo se aplicará a esa página".3 Un editor gana cuando un lector sigue el enlace de una burbuja, y una burbuja solo puede abrirse donde se ejecutó el script incrustado. Un script pegado en un campo de una página puede producir burbujas en esa única página, y el campo para todo el sitio es el que pone el script incrustado en todas las páginas.