DOMina el contenido de tu web

Resumen de la ponencia

Carlos Sánchez abrió el evento con una promesa: dejar al público sin palabras. Concretamente, sin las palabras “no se puede”, esa respuesta tan habitual cuando un SEO pide un cambio en la web y el programador de turno se niega. Para desmontarla, repasó las cuatro formas posibles de modificar el contenido de cualquier página web, con sus ventajas y desventajas.

Las formas clásicas: código original y base de datos

La primera opción es tocar el código original. Es la vía más limpia: cualquier bot, incluido Googlebot, entiende el cambio a la perfección y el rollback es sencillo. El problema es que exige conocimientos de programación y saber muy bien dónde tocar; si modificas el core de un WordPress, una actualización puede fastidiarlo todo.

La segunda es la base de datos. En su versión más simple es algo que todos hemos hecho: cambiar un texto desde el backend del CMS, sea WordPress, Shopify o PrestaShop. En su versión avanzada, Carlos mostró cómo hacer reemplazos masivos desde phpMyAdmin o directamente con MySQL. Los bots lo leen perfectamente porque el cambio se hace en origen, pero no hay Ctrl+Z: sin copia de seguridad, te puedes cargar la web por completo.

JavaScript: cambios sin acceso al código

La tercera vía es JavaScript, y aquí Carlos dio dos palabras mágicas para pedírselo a cualquier LLM: outerHTML e innerHTML. Con ellas se puede cambiar, eliminar o construir cualquier elemento de la página. Y lo mejor: si tienes Google Tag Manager, puedes inyectar ese código sin tener acceso directo a la web, quitando por ejemplo una tabla de precios o un botón de WhatsApp que nadie te deja tocar.

Las desventajas: el típico “flashazo” al cargar la página y los problemas de interpretación. Si cambias un noindex a index por JavaScript, Google verá el noindex original y no renderizará, mientras que otros bots como GPTBot lo ignorarán directamente. El HTML que llega al navegador y lo que entiende cada bot no siempre coinciden.

El buffer de PHP: la estrella de la ponencia

La cuarta forma fue el plato fuerte: el buffer de salida de PHP, una técnica que existe desde los años 2000 y que todos los CMS usan internamente. La idea es interceptar el HTML final justo antes de enviarlo al usuario y modificarlo a la carta, sin importar el código, el builder o el plugin que haya detrás. Carlos tiene todo el detalle técnico explicado en su artículo sobre cómo modificar el HTML con el buffer de PHP.

Con el buffer se puede llegar a una hiperpersonalización total: envolver caracteres concretos en etiquetas para cambiarles la tipografía, generar metaetiquetas a la carta, o eliminar archivos CSS y JavaScript de plugins cuando no se detecta el formulario que los necesita. Y a diferencia de la base de datos, el rollback es trivial: comentas el parche y la web vuelve a su estado original.

Ronda de preguntas

En el turno de preguntas, Carlos explicó dónde colocar el buffer según el CMS: cualquier archivo de configuración que se lea en todas las páginas, como el functions.php o incluso el wp-config.php en WordPress, o los archivos de configuración de PrestaShop y Magento. También advirtió que reconectar con la base de datos desde el buffer añade tiempo de carga, por lo que su recomendación es usarlo solo para modificar el HTML de salida.

El mensaje final: la próxima vez que un programador te diga que “no se puede”, pásale esta ponencia. Con el buffer, siempre hay una manera.