SEO en Drupal

 Bienvenido o bienvenida a un episodio más de este podcast. Y primero de todo quiero dar las gracias a Dani por darme feedback, ¿vale? De episodios pasados. Básicamente Dani me ha dicho que soy un negado para el marketing y toda la razón del mundo. Soy programador, no gente de marketing. Y me ha dicho de que claro que está muy bien que tenga un podcast que hablo de Drupal, pero normalmente no digo ni el nombre del podcast, ni mi nombre, ni la temática del podcast, ni dónde me pueden contar la gente, ni nada de nada. Soy horrible en marketing. Así que por culpa de Dani hoy os vais a comer un poco de spam de mí. Primero de todo, este podcast es Drupalízate. Solo hablo de cosas de Drupal. Si vienes del mundo WordPress y vas a seguir usando WordPress como herramienta, no sé cómo me has encontrado y no sé por qué estás escuchándome. Yo de ti pausaba y me iba a otra cosa. Si eres de mundo Drupal, tienes una web en Drupal o quieres empezar a hacer webs en Drupal, por qué deberías escucharme? Pues porque me llamo Robert Menetrai, soy freelance actualmente y antes de eso trabajaba para varias agencias. Llevo varios años trabajando exclusivamente con Drupal. Empecé con Drupal 7 y ya estamos ya con Drupal 9. ¿Vale? Y aparte de esto, bueno, me puedes encontrar en mi web menetrai.com. Soy muy original, o sea, Menetrai es mi apellido, con Y final, pues menetrai.com. Ahí me puedes contactar ya sea para consultorías o para darme feedback de este mismo podcast. Si en vez de esto no me quieres contactar en mi web, me puedes encontrar en el LinkedIn buscando por Robert Menetrai y nada, ahí tengo una newsletter también donde aparte de hacer un poco de spam de este mismo podcast, también comparto semanalmente las noticias que me encuentro de mundillo Drupal, también comparto si sale alguna actualización de seguridad del código de algún módulo y también comparto algunos artículos de mi blog o de algunas entrevistas que he encontrado de gente relevante de este mundillo. Y nada más, ya he hecho todo lo spam. Esta semana, o este episodio de esta semana, toca hablar sobre SEO, o es mi intención, ¿vale? En si es bueno o es malo en Drupal, primero de todo quizás sería mejor explicar qué es el SEO y después quiero acabar hablando sobre algunos módulos que deberías tener sí o sí o que se sean muy recomendables que tenga tu web instalados. Primero de todo, ¿qué es el SEO? A ver, entiendo que la mayoría de gente ya lo sabe, pero por si acaso, si alguien aún despistado ha llegado hasta aquí, el SEO es la optimización para motores de búsqueda, ¿vale?, el search engine optimization en inglés. Básicamente es aparecer en Google, aparecer en la primera página en Google. Si no apareces en Google, la gente no te encuentra. Si la gente no te encuentra, no llega a tu web y no te contratan, no te pagan, no compran tus productos. El SEO es importante porque te trae clientes de forma orgánica y de forma gratuita. Bueno, gratuita relativamente, porque si tienes que gastar dinero en optimizar tu web, gratuita es relativo. O sea, no siempre gratuito, gratuito. Pero bueno, es mejor que no gastes dinero semanalmente en publicidad. Volviendo al tema que me estoy viendo, por ramas. El SEO, digamos que tenemos dos ramas muy distintas, muy diferenciadas, lo que es SEO de contenidos y lo que es SEO técnico. Yo en el SEO técnico englobo todo lo que nos dé contenidos. ¿Qué es SEO de contenidos? Pues básicamente el contenido de la web, que normalmente son textos, el que te genera los textos. No es solo generar textos masivamente en la web, sino que tienes que tener en cuenta siempre la intención de búsqueda del usuario. No es lo mismo tener un proyecto, por ejemplo, enfocado a responder la intención de búsqueda del usuario de busco el número ganador de lotería, donde el usuario únicamente quiere saber el número que ha ganado. Por mucho que hagas artículos muy largos explicando cómo funciona la lotería o cómo puedes ganar la lotería, la persona que busca el número ganador quiere saber el número, no quiere leerse un artículo de 3,000 palabras. Esa es la intención de búsqueda del usuario. De la misma forma que alguien que busca la edad de Donald Trump no quiere ir a una web donde salga un artículo explicando la vida de Donald Trump, quiere saber la edad, punto. Y por ejemplo en estos dos casos Google puede responder directamente la respuesta que espera el usuario sin que el usuario tenga que ir a una web. En este caso es un SEO muy complicado porque tu web no va a traer visitas porque Google directamente muestra la respuesta ya en su propio buscador. Otros ejemplos pueden ser, por ejemplo, el cálculo de impuestos en España. Cuando alguien busca, por ejemplo, cómo calcula la renta, normalmente esperan encontrar una herramienta, una calculadora. No esperan encontrar un artículo o un conjunto de artículos donde se explica cómo calcula la renta, quieren una herramienta que sea fácil de usar. Y lo mismo va, por ejemplo, en herramientas SEO. La gente normalmente espera encontrar una herramienta o se posiciona mejor una herramienta que no artículos muy largos explicando cómo funcionan las herramientas. Depende del sector, o sea depende del tipo de competencia que tengas en tu web se cumplen estas condiciones o se cumple simplemente generar artículos en el blog se pueden posicionar. Como digo depende mucho de tu nicho, de tu competencia. Y de esta parte no puedo comentar mucho más porque yo no soy experto en SEO y no, mejor dicho, no soy experto en SEO en contenidos. Que sepas que las partes más importantes vas a tener siempre en cuenta la intención de búsqueda del usuario y si en el caso de la intención de búsqueda vas a encontrar textos buenos has de saber generar estos textos buenos. Y hasta aquí. El siguiente apartado SEO técnico. ¿Qué es el SEO técnico? Todo lo que nos contenidos. Esto puede significar desde mejora del rendimiento de la web, desde asegurarte que tengamos todas las metaetiquetas puestas, que tengamos que estemos usando H1, H2 por ejemplo, que las URL sean amigables, que la parte del frontend no tenga problemas en el Lighthouse de Google por ejemplo. Al final muchas cosas a tener en cuenta que no son de contenidos, que normalmente son cosas más técnicas, que normalmente son cosas que se subcontratan a un programador, por así llamarlo, ¿vale? Y es donde me voy a enfocar más en este episodio. Y antes de pasar a qué módulos recomiendo poner, te tengo que contar si Drupal es bueno o malo en SEO técnico o SEO de contenidos. Primero de todo el SEO de contenidos, como supongo que puedes imaginar, depende mucho de los contenidos. No depende en nada de si usas WordPress, Drupal o otra tecnología. Depende exclusivamente de cómo estén montados tus contenidos, ¿vale? Así que ¿Drupal es bueno en SEO de contenidos? No es bueno ni es malo, es una herramienta. ¿Drupal es bueno o malo en SEO técnico? Digamos que no es el mejor, al menos no salió de caja, te voy a ser sincero, no es sin hacer nada, Drupal no es la leche en SEO técnico, pero tampoco es malo. Digamos que está en un punto medio, o sea, de un... si el punto hacemos del 0 al 10, yo quizá le pondría un 6 tirando a 7, ¿vale? Es bueno, es decentemente bueno en SEO técnico sin hacer nada. Hay cosas a mejorar, pero sin hacer nada es decentemente bueno, ¿vale? ¿Cómo se puede mejorar? Por ahí viene la pregunta. ¿Cuáles son los problemas que puedes tener en un Drupal con SEO técnico? El problema principal normalmente es el frontend, es cómo esté hecho el tema visual de la web. No es por detrás ser un Drupal, sino cómo está hecho el tema. Yo me he encontrado guarradas de agencias o solicitudes un poco guarradas de clientes o de agencias para hacer cosas que digamos no son muy buenas prácticas. Por ejemplo, que por diseño visual determinadas páginas no tienen títulos, no hay H1, no hay H2, esto a Google como que no le gusta. O sea, le gusta ya más tener un H1 siempre. Yo se los comenté a las agencias de ver, no tiene sentido de que estas páginas no tengan H1. Aparte, son páginas importantes. O sea, son páginas que se busca que estén indexadas en Google. Así que deberían tener algún tipo de H1. Y la respuesta fue bueno. Sí, es verdad, ya, pero por diseño no puede tener un título aquí medio grande. No, lo que haremos es que en el webcam, la parte final del webcam que se corresponde con el título de la página actual, vamos a poner allí que pongas un H1 en código. Y es un, bueno a ver, pero según Google los H1, H2, H3 han de ser de mayor tamaño en texto que el contenido central de la web y normalmente se recomienda que sean en negrita. O sea, que se destaque de alguna forma comparándolo con el contenido central de la web. Y el webcam que es más pequeño y no está en negrita y apenas se percibe, esto no es bueno prácticamente, lo comunico a uno. Bueno, pues en ese proyecto en concreto, los de la agencia dijeron que sí, que por huevos esto iba así. Y es un bueno como me pagáis vosotros porque mi cliente en este proyecto es la agencia, no es cliente final. Pues vale, pues lo que me digáis. Esto te lo pongo como un ejemplo para que veas que si tú como cliente contratas a una agencia, no siempre van a ver o van a buscar las mejores prácticas para SEO. Si las has contratado porque es un diseño molón, pues se han hecho un diseño molón, no se han preocupado de que tengas un buen SEO. Y eso, como digo, depende mucho de quien te haya hecho la web y si priorizabas las partes visuales o priorizabas las partes de rendimiento o priorizabas las partes de SEO. O un poco de todo. Otros ejemplos así un poco raros que me he encontrado. Meter displays nones para ocultar textos o imágenes en la web. También son muy malas prácticas en SEO, pero hay agencias que me lo han pedido. Yo, bueno, lo que tú me digas, que sepas que está mal, pero bueno, si tú me pagas yo te lo hago. Como digo, depende mucho de quién te haya hecho el frontend. Y como digo, yo soy parte de la curva. A mí sí me pagan por hacer esto y lo confirmo de que sepas que esto está mal, ya, ya, pero que lo hagas. Bueno, pues lo hago, bueno, pues digamos las partes más oscuras de hacer webs. Cuando te entiendes más el dinero que lo que es el, lo que recibe cliente final. Sobre todo cuando en esos casos yo trabajaba medio como marca blanca y cliente final, yo no sabía que yo existía, sino que básicamente como si yo fuera trabajador de la agencia, que se hace mucho en este mundillo de hacer webs. Bueno, temas varios, ¿vale? Al final depende mucho cómo está hecho el frontend de la web y cómo de, como digo, cómo de bueno sea en rendimiento o en carga de la página. Porque es una de las cosas que también afecta mucho. Me encuentro webs que son lentísimas por problemas de que el que ha hecho el frontend no ha tenido en cuenta apenas nada en temas de rendimiento. Desde meter, por ejemplo, logs y ocultar los logs con display nodes. O sea, tú verías el código HTML de la web y encontrabas los logs de temas de renderizar campos y los ocultan por display node después. No mal que la web vaya lenta. Bueno, que me estoy yendo por las ramas. Drupal es bueno o malo? Es una herramienta. No es ni bueno ni malo. Depende mucho de cómo se use la herramienta, ¿vale? Yo creo que te puedes quedar con eso. Siguiente, porque si no, no me va a dar tiempo con este episodio, que quiero que sean cortos y no hay manera. Quiero hablarte de los módulos que te recomiendo o las cosas que te recomiendo más básicas para temas de SEO, ¿vale? Drupal, primero de todo, Drupal por defecto no te da URL limpias. Una URL limpia, por ejemplo, es el dominio.com barra el nombre o el título de la página. Eso es una URL limpia. Drupal lo que te da por defecto es dominio.com barra node barra ID del nodo. Eso muy limpio no es. Vale, es corto, ¿vale? Pero no es limpio. Y Google prefiere que las URL contengan las palabras clave. Normalmente es el título de la página, pero Google prefiere que sean textos las URL. Aquí en Drupal tenemos un módulo que es contribuido y completamente gratuito que se llama path auto, ¿vale? Que te permite configurar automáticamente las URL. Dicho de otra forma, te permite configurar de forma muy detallada que ciertos tipos de página van a tener un patrón de URL y ciertos tipos de página distintos van a tener un patrón de URL distinto. Por ejemplo, queremos de que las páginas del blog sean blog barra título del blog y las páginas de producto queremos que sean categoría padre barra categoría hijo barra título de producto. Por ejemplo, pantalones barra pantalones cortos barra el nombre del pantalón de la marca del producto. Por ejemplo, o sea, al final es depende el tipo de proyecto puede tener sentido que solo tengas el título como parte de la URL o puede tener sentido que pongas otros campos porque puedes poner cualquier campo en la URL. Como digo, puede ser desde poner la fecha en la URL porque hay un campo de fecha, puede ser que quieres poner el nombre del autor porque hay un campo que es el usuario, puede ser que quieres poner varias categorías porque hay varios campos de categoría. Depende de cómo te lo quieres montar, es siempre flexible y muy recomendable tener las URL limpias. Esto es más que nada porque en tu propio defecto sí que puedes poner URL limpias pero las tienes que poner a mano. O sea, cada vez que quedas una página has de poner escribir a mano la URL y sinceramente la mayoría de usuarios se saltan este paso. Ponen título, texto, guardar y ya está. No van a editar la URL manualmente. Por eso recomiendo este módulo porque una vez configurado, automáticamente cada vez que se guarda una página, genera la URL nueva. Con esto podemos tener un pequeño problema. Ya te voy a decir cuáles y cómo se soluciona. El problema es URLes viejas que dejan de existir. Por ejemplo, tenemos un artículo de un blog y la URL es blog barra el título de ese post. Si de aquí a una semana o de aquí a un mes o de aquí a un año cambiamos el título de ese blog, cuando guardamos el path auto lo que hará es, el título se ha cambiado, podemos cambiar la URL para que se corresponda con el título. Eso significa eliminar la URL vieja y poner la nueva. ¿Y qué pasa? Que tenemos dos opciones. Si eliminamos la URL vieja, nos va a dar un 404. Eso significa que si esa URL estaba posicionada en Google, vamos a perder esa posición en Google. Google la va a desindexar porque esa página dirá que es un 404, una página inexistente. Otra opción es, no, no eliminamos la URL, dejamos la vieja y la nueva, con lo cual tenemos dos URLes que apuntan al mismo contenido. Lo que significa que es contenido duplicado, lo que significa que Google te puede penalizar por tener contenido duplicado. Tampoco es bueno tener páginas, dos URLes para la misma página. Es más, Drupal por defecto te elimina la URL vieja siempre. Aquí entra otro módulo que se llama redirect. El módulo redirect lo que hace es cada vez que se elimina una URL, en vez de eliminarla, la elimina y hace una redireccionada nueva, con lo cual la gente que siga entrando a la URL vieja, sean redirigidos con un 301, que es bueno en SEO, sean redigidos a la nueva versión. Con lo cual Google, cuando entra a la web, a la URL vieja, dirá, ah, que hay una redirección, vale, pues he de pasarle el posicionamiento a la URL nueva y quitar la vieja. Pero no pierdes el SEO de las web, de las URLes existentes, ¿vale? Es un módulo muy interesante, sobre todo para temas de contenido duplicado y para evitar tener páginas 404. Y aquí un apunte también, que no es bien bien para web Drupal, sino es para cuando migras contenido de otras webs. O sea, cuando tienes una web, por ejemplo, en WordPress o en otra tecnología y la migras a Drupal, el que te hace la migración debe tener en cuenta migrar también las URLes para que nunca se dé el caso de que haya un 404. O se migra la URL como tal y la página mantiene la misma URL que tenía antes, o se generan redirecciones nuevas para que las URLes viejas apunten a las URLes nuevas en la web nueva en Drupal. Te lo digo porque me he encontrado en varios casos que esto la agencia no ha tenido en cuenta y después el cliente final se daba cuando al cabo de un mes de que había perdido mucho posicionamiento SEO porque muchas URLes daban 404. Lo digo solo para que lo tengas en cuenta. Dicho esto, siguiente módulo. Hemos repasado el pathauto que es generar URLes. El redirect que es cuando se eliminan URLes generar las redirecciones correspondientes. Ahora viene cosas que ya no son de URLes como tal, sino que son las metaetiquetas. Las metaetiquetas, para quien no lo sepa, digamos que son como fragmentos de código que no son visibles en el frontend de la web, pero que sí que lo usan muchas herramientas, las cuales están por ejemplo el buscador de Google, está en Facebook, LinkedIn, en Twitter y básicamente todas las redes sociales. Así que afecta a cómo se comparte el contenido en redes sociales y afecta a cómo lo ven los motores de búsqueda, ya sea Bing, Google, ya en Dex, los que sean. Sobre todo Google, que es el 90 y pico por ciento de las búsquedas, sobre todo en la escuela hispana e inglesa, en Europa y América es el que más se usa. Total los meta tags. Drupal por defecto tiene unos meta tags, digamos un poco pobres. Sé que te genera un meta título, pero no es flexible para configurarlo y no te permite poner otras metaetiquetas que en algunos proyectos te puedan hacer falta. Aquí entra en juego el módulo meta tags, que te permite literalmente tocar cualquier meta tag. Desde el meta título, meta descripción y otras meta etiquetas digamos más genéricas a también tocar las meta etiquetas de redes sociales o de Twitter en concreto. Porque en algunos casos por ejemplo Twitter tiene meta etiquetas distintas que otras redes sociales, donde puedes especificar si al compartirlo se va a usar un cart con imagen o no o cómo se va a usar. ¿Por qué estoy recalcando tanto esto de redes sociales? Puede ser por ejemplo que tengamos un artículo en el blog que hayamos subido por ejemplo una imagen destacada. Lo más típico que se pone una imagen en la cabecera y para que tenga un poco más de actividad visual y después viene el texto. Cuando compartes en redes sociales y no tienes ningún tipo de meta etiqueta, Facebook o Twitter o quien sea, entra en tu web y dice ah, en el código no me especifica qué imagen he de usar. Bueno, voy a ver qué imágenes hay y la que más me gusta es la que uso yo automáticamente al compartirlo. Con lo cual la decisión de qué imagen se ha de usar, recalle en Facebook o Twitter. Y en algunos casos sí que usan la que tú esperabías, en este caso la imagen de cabecera, pero en otros casos me he encontrado que usan por ejemplo el logotipo de la web o una imagen del footer o la imagen del autor del post, porque sale la cara de la persona que ha escrito. O sea, cogen una imagen random que está en esa página, lo cual no siempre es lo que queremos, ¿vale? Del mismo modo los textos que se comparten, el título o la descripción, no siempre coge lo que se esperaría. En resumen, es más recomendable tener las meta etiquetas bien configuradas para especificar a Facebook, Twitter, LinkedIn, a quien sea, de que se ha de usar esta imagen y ese texto y no esperar que las redes sociales cojan lo que tú esperas que ellos cojan. Es mejor especificárselo. Y lo mismo pasa en Google, por ejemplo, el meta título o meta descripción o los textos enriquecidos, depende si queremos, yo qué sé, temas de ubicaciones o especificar si esta página habla de contenido de una persona o habla de contenido de una oferta de empleo, a final hay textos enriquecidos como meta etiquetas que especifican a Google que este contenido de esta página es una cosa u otra, es un artículo, es una oferta de empleo, es el perfil de un usuario. Digamos que se puede afinar mucho y especificarle a Google de forma mucho mejor, más detallada, de qué estamos hablando en esta página. Y esto hay muchas webs que no lo tienen configurado y no lo usan. Así que recomiendo bastante usar MetaTags. Una cosa que no he comentado es tanto Pathauto como MetaTags usan el módulo token. El módulo token, digamos de forma simplista, que te permite, te genera variables que son tokens. Por ejemplo, en el Pathauto, cuando especificas de que la URL contiene el título, pues nuevamente pones el, creo que era node dos puntos title. Es el token que se reemplazará con el título del nodo. Cuando usamos el MetaTags es lo mismo. Si queremos que automáticamente el título, Metatítulo sea el título de la página, pues pondremos el token del título. Si queremos que la imagen para Facebook sea la imagen destacada, vamos a poner el token de la imagen destacada con el estilo de imagen que queramos. Vale, o sea, finales, jugamos con los tokens para autorrellenar y automatizar la generación de meta etiquetas y la generación de URL. Y ya no sólo jugar con token, sino que vamos jugar con los token y concatenarlos, juntarlos con texto fijo. Por ejemplo, el Metatítulo puede ser el título de la página y un espacio, un guión, una barra y poner el nombre de la web, por ejemplo, o el nombre del producto o lo que nos interese. Al final es jugar con la flexibilidad que nos da. Vale, y para acabar, cuando he dicho estilos de imagen, lo de poner meta etiquetas para que Facebook coja una imagen con su estilo de imagen correspondiente, quizá hay gente que sabe de lo que estoy hablando, pero hay gente que diría estilos de imagen, ¿esto qué es? Digamos que en Duplar por defecto tienen dos módulos, uno que es estilos de imagen y otro que es imágenes responsivas o responsive image. El primero, estilos de imagen, lo que te permite es que cada vez que un usuario sube una imagen, por ejemplo, han subido una imagen de cabecera para el blog que pesa, yo qué sé, cuatro niggas, una burrada, pesa muchísimo para ser una imagen para el blog. Pero claro, normalmente los usuarios que editan textos en la web, hay gente que no sabe si una imagen pesa mucho o poco. Han hecho una foto con el móvil y suben la foto y ya está. Han cogido la primera imagen que han encontrado en Google y suben esa imagen y no se han preocupado si es una imagen que pesa mucho o pesa poco. No se han preocupado si se va a ver bien en móvil o se va a ver mal. Los estilos de imagen en Duplar los configuras y especificas que, por ejemplo, en el listado del blog todas las imágenes que salen allí van a usar el estilo de imagen que tú has configurado para ese listado. Y si la misma imagen se usa en la página de detalle del artículo, se va a usar un estilo de imagen distinto. Esto es, por ejemplo, porque queremos que todas las imágenes que se mostren en el listado tengan un formato, por ejemplo, más cuadrado, ¿vale? Con el mismo alto y ancho, son cuadrados visualmente. En cambio esa misma imagen en la página de detalle, en la cabecera, si es que se pone allí, queremos que sean imágenes más panorámicas. Porque por diseño se quiere que la imagen ocupe, por ejemplo, del 100% del ancho o lo que sea. Y, por lo general, te permite usar la misma imagen en varios contextos, por así llamarlo, y configurar que tengan distinto tamaño, que en uno, por ejemplo, le voy a poner una marca de agua, en el otro le voy a poner en blanco y negro y en el otro, yo qué sé, ya depende de cada proyecto. Entonces, alteras la imagen. Puedes hacer realmente virguerías. Puedes superponer una imagen con otra, que vienes a una marca de agua, o recortar o redimensionar o centrar la imagen o girar, rotarla o lo que sea. Y después entra en juego otro módulo, que es el Responsive Image. Ese módulo que te permite es, vale, ya he generado un estilo de imagen que es para el listado del blog. Pero claro, esas imágenes que se usan aquí, para escritorios también, pero para dispositivos móviles son un poco demasiado grandes. Quizá tendría más sentido hacerlas más pequeñas en móviles. Pero claro, es la misma página, solo que es de un tamaño de dispositivo distinto. ¿Cómo se gestiona esto? Pues Drupal te permite hacerlo de forma muy simple. En el módulo Responsive Image, configuras un grupo de imágenes, de estilos de imagen, para que funcionen juntos. Después configuras que en el listado del blog, en vez de usar el estilo de imagen, usan el estilo de imagen Responsive. Con lo cual, automáticamente, cuando redimensionas las pantallas, o sea, usas un dispositivo, por ejemplo, un móvil, una tablet o un escritorio, vas a ver una imagen distinta para cada uno de los dispositivos. En verdad la misma imagen, con un estilo de imagen distinto. Pues en uno, sea más panorámico o más recortado, o uno tendrá, se dan el mismo estilo, sean todos panorámicos, pero uno tenga un ancho de 150 píxeles, el otro de 500 y el otro de 1024. Pero, me estoy inventando, sobre la marcha, pero esto es la ventaja de, pues jugamos con alturas y anchos, para que en móviles pese mucho menos, sea una imagen mucho más pequeña, que no en escritorios. El módulo, los dos módulos de imágenes, en muchos proyectos me encuentro que no los usan y esto afecta muy negativamente al SEO, porque Google lo tiene muy en cuenta, cuando hay imágenes que tienen un tamaño desproporcionado. La web carga mucho más lento en el frontend y Google lo penaliza muchísimo. Es una cosa que se tiene que tener en cuenta. Drupal por defecto viene con esto, por claro, si en el diseño de tu web se han quedado secciones de productos, de blog, de lista de productos, lista del blog, la home, páginas básicas, lo que sea, y no se han configurado estos estilos de imagen, aunque en Drupal estos módulos bien activados por defecto se han de configurar. Y me encuentro en muchísimos casos que no están configurados, realmente no se están usando o peor aún, directamente no usan el renderizado de imágenes de Drupal, sino que lo hacen por código custom todo, que no entiendo por qué. Bueno, sí lo entiendo, son agencias que no saben cómo va, no saben cómo funciona Drupal, lo hacen picando a fuego básicamente el código. Esto es para acabar, de que veas, de que no es si es Drupal bueno o malo, es una herramienta y depende mucho de cómo la use la agencia o el freelance que le ha hecho la web. Hay buenas prácticas y hay malas prácticas, y sea porque yo trabajo de esto, pero me he encontrado normalmente más gente que usa las malas prácticas que no las buenas. Y nada más, que me ha agradado mucho con esto, casi media hora. La semana que viene seguramente habré algo similar, pero para temas de rendimiento, ¿vale? Así que si te interesa el tema, suscríbete y estáte atento a la semana siguiente, que seguramente sea similar. Habaré de algunos módulos recomendados y algunas buenas prácticas para tener en cuenta, para tener una web lo más rápida posible. Y nada más, hasta la semana que viene. Chao.