Ruby on Rails: ¿se puede modificar el SEO desde el frontend?

Hola, betas:

¿Alguien podría echarme una mano con Ruby?

Estoy trabajando sobre un sitio desarrollado con Ruby y necesito entender hasta qué punto es posible intervenir sobre el framework, especialmente en dos aspectos:

• modificar la arquitectura y la estructura de determinadas páginas;
• añadir o modificar datos estructurados (Schema.org / JSON-LD) en páginas de servicios.

Mi duda principal es: ¿este tipo de modificaciones se pueden realizar directamente desde el frontend o necesariamente hay que intervenir en el backend / plantillas del proyecto?

También me interesa conocer los riesgos: conflictos con el framework, problemas durante futuras actualizaciones, duplicación del marcado estructurado, errores de renderizado, etc.

Si alguien ha trabajado con Ruby o Ruby on Rails en este tipo de proyectos SEO, me interesaría mucho conocer vuestra experiencia.

¡Gracias de antemano!

Sí se puede, pero depende de qué llames frontend y de cómo esté montado el sitio. Primero confirmaría que usa Ruby on Rails: Ruby es el lenguaje y no todos los sitios hechos con Ruby utilizan Rails.

Si es una aplicación Rails que genera el HTML en el servidor, para cambiar encabezados, bloques de contenido, enlaces internos o metadatos normalmente trabajarías en sus vistas y layouts, dentro de app/views. Es la capa de presentación, aunque esas plantillas se ejecuten en el servidor. No necesitas modificar el código del framework para eso.

Si con «arquitectura» te refieres a cambiar URLs, crear nuevas páginas o modificar qué información carga cada una, entonces también pueden intervenir las rutas —config/routes.rb—, los controladores y, según el cambio, los modelos. Si solo quieres reorganizar el contenido de una página existente, no implica necesariamente tocar todas esas capas.

Para JSON-LD, mi primera opción en ese escenario sería generarlo desde los mismos datos que usa la página y renderizarlo mediante una plantilla parcial o un helper. Así, cuando cambias un servicio, no tienes que mantener por separado el texto visible y una copia del Schema en otro sitio.

También puedes insertarlo con JavaScript o Tag Manager; Google contempla esa posibilidad. Pero hay que comprobar el HTML renderizado: un error de JavaScript o una condición que impida ejecutar la etiqueta puede dejar el marcado fuera. Si Rails solo sirve una API y el frontend está en React, Vue u otra tecnología, habría que revisar cómo ese frontend genera las páginas.

Sobre los riesgos que mencionas, revisaría esto antes de publicar:

• Qué marcado existe ya y quién lo genera: plantillas, alguna gema o Tag Manager. Tener varios bloques JSON-LD no es un error por sí solo; el problema es duplicar la misma entidad con datos contradictorios.
• Que los cambios queden en el código de la aplicación y se prueben aparte antes del despliegue. Una actualización de Rails no debería obligarte a rehacer todo el SEO, pero sí hay que verificar compatibilidad y renderizado.
• Si cambias URLs, preparar las redirecciones y actualizar enlaces internos, canónicas y sitemap.
• Validar el Schema y comprobar los tipos compatibles con los resultados enriquecidos de Google. Que un marcado Service sea válido no garantiza un resultado enriquecido ni una mejora de posiciones.

¿Tienes acceso al repositorio y sabes qué versión de Rails y qué plantillas/frontend usa? Con ese dato y un ejemplo concreto de la página que quieres cambiar se puede indicar dónde intervenir.

Te dejo las referencias oficiales:

¡Muchas gracias, Carlos, por una respuesta tan completa!


He revisado el código fuente y confirmo que es una aplicación Ruby on Rails con renderizado en servidor: aparece el meta csrf-token, los assets con huella (/assets/application-<hash>.css) del asset pipeline y el campo oculto utf8=✓ en los formularios. Esto último y el Bootstrap 4 en versión alfa me hacen pensar en un Rails 5.x o anterior; voy a pedir el Gemfile.lock a la agencia para confirmarlo, porque si es así ya no recibe parches de seguridad.


Te detallo lo que necesito hacer, por si me puedes confirmar dónde intervenir:

1. Sitemap: genera URLs con doble barra (dominio.fr//ruta). Supongo que viene de una concatenación del host con la ruta en la gema o en la vista .builder. ¿Lo corregirías usando los helpers *_url o ajustando el default_host?
2. JSON-LD por tipo de página: ahora no hay ningún JSON-LD, solo un bloque RDFa antiguo de data-vocabulary.org en el footer, que quiero eliminar. Mi idea es un content_for :json_ld en cada vista, generado desde el modelo, y un yield :json_ld en el layout: RealEstateAgent global con un @id fijo, RealEstateListing con Offer en las fichas (con availability InStock o SoldOut según el estado del bien en la base de datos), ItemList en el listado, Article en las noticias y BreadcrumbList. ¿Te parece el enfoque correcto en Rails, sobre todo para escapar bien el JSON?
3. Entidad: quiero reconciliar la entidad con al menos cinco sameAs y desambiguar algunas páginas sobre grupos empresariales, con un about hacia la Organization correspondiente.
4. URLs con slug + ID: he visto en Search Console variantes del tipo /noticias/texto-cualquiera-35 que responden 200. Parece que el controlador busca solo por el ID e ignora el slug. ¿Recomendarías una redirección 301 en el controlador cuando el slug no coincide con el canónico?
5. Seguridad: si el sitio empieza a posicionarse en búsquedas transaccionales, tengo previsto poner un WAF delante (tipo Cloudflare). ¿Alguna precaución con Rails, por ejemplo con el token CSRF, el reCAPTCHA o la caché?

¡Gracias de nuevo!

¡Gracias a ti! 🙂 Con lo que describes ya se puede concretar bastante. Tu enfoque va bien, con algunos matices para que los cambios de SEO no te creen problemas de URLs, renderizado o sesiones.

Primero, esos indicios son compatibles con Rails, pero no permiten fechar la versión: una aplicación actualizada puede conservar plantillas y dependencias antiguas. Gemfile.lock te dará una referencia mucho más fiable; conviene contrastarla con lo que realmente está desplegado. Si se confirma Rails 5.x, está fuera del mantenimiento oficial y habría que planificar su actualización, sin mezclar una migración grande con todos estos cambios a la vez.

1. Sitemap y dobles barras

Lo corregiría donde se generan las URLs, después de localizar la concatenación concreta. No daría por hecho que la causa es default_host sin ver ese código.

Si usa la gema sitemap_generator, revisaría config/sitemap.rb: default_host con la URL base HTTPS, sin barra final, y las rutas generadas con los helpers *_path que se pasan a add. Si es una vista .builder propia, preferiría los helpers *_url, con host y protocolo de producción configurados explícitamente cuando se ejecuten fuera de una petición web.

Son dos formas de construir la URL; no concatenaría otra vez el host delante de un helper que ya devuelve una URL completa. Tampoco haría una sustitución global de dobles barras, porque podrías estropear https://.

Después regeneraría el XML y comprobaría que sus URLs son las canónicas, responden 200 y coinciden con los enlaces internos. Si las variantes con doble barra ya existen públicamente y representan la misma página, añadiría una redirección permanente a la correcta, sin cadenas. Arreglar únicamente el sitemap no elimina esas variantes.

2. JSON-LD, content_for y escape

Sí, content_for :json_ld en las vistas y yield :json_ld en el layout es un enfoque válido. Cuidaría el orden: el bloque tiene que estar definido antes de que el layout lo emita. Para mantenerlo, construiría los datos mediante un helper o presenter que lea los modelos, y dejaría la vista encargada de renderizarlos.

Para el escape, dentro de la etiqueta script de tipo application/ld+json, el patrón ERB es:

<%= raw(json_escape(datos_schema.to_json)) %>

Aquí datos_schema es el Hash/Array que construyes con los campos públicos que quieres marcar. Primero se serializa a JSON válido; después json_escape protege caracteres que podrían cerrar la etiqueta script. raw se aplica al resultado escapado. No usaría .html_safe directamente sobre texto de usuarios ni volcaría un modelo completo con datos privados. Este patrón también está documentado en Rails 5.2, aunque debes contrastarlo con la versión real del proyecto.

La distribución que propones tiene sentido: RealEstateAgent con un @id estable; RealEstateListing para la ficha, con su Offer; ItemList para el listado, Article para noticias y BreadcrumbList para las migas. Distinguiría la ficha del inmueble físico y conectaría las entidades mediante @id, usando propiedades válidas para cada tipo. availability va en Offer y debe reflejar el estado real que también ve el visitante.

Puedes conectar las entidades por @id, en uno o varios bloques. No es obligatorio reunirlo todo en un único script. Al cambiar el estado del inmueble, invalida también la caché de la ficha para que el marcado no siga ofreciendo algo vendido.

Sustituiría el marcado data-vocabulary.org obsoleto, conservando el contenido visible del footer que sí sea necesario. Y validaría dos cosas distintas: el vocabulario con Schema Markup Validator y la elegibilidad de los tipos que Google admite con su prueba de resultados enriquecidos. Un RealEstateListing válido no garantiza un resultado especial en Google.

3. Entidades y sameAs

No hay un mínimo de cinco sameAs. Pondría solo referencias que identifiquen inequívocamente a esa misma entidad: perfiles oficiales o fichas fiables, si existen. No rellenaría la lista con directorios dudosos para alcanzar una cantidad.

about hacia la Organization correspondiente encaja si esa página realmente trata sobre ella. Mantendría @id distintos para la agencia, cada grupo empresarial y cada inmueble. Compartir nombre o pertenecer al mismo grupo no convierte dos sociedades en la misma entidad. Esa coherencia ayuda a describirlas; no garantiza por sí sola su reconciliación en Google.

4. Slug + ID y redirección

Sí: si varias URLs representan exactamente la misma noticia, redirigiría las variantes a su URL canónica. Lo haría en la acción de lectura, después de cargar el registro y comprobar que sea público y accesible, generando el destino con el helper y el slug canónico del propio registro.

Compararía la ruta recibida con esa ruta canónica; no construiría el destino con un host o una URL aportados por el visitante. Para GET/HEAD, una 301 es adecuada. No extendería esa regla indiscriminadamente a formularios o peticiones POST.

La prueba sería: slug correcto devuelve 200; slug inventado con ID válido devuelve una sola redirección a la noticia correcta; ID inexistente devuelve 404; y no aparece ningún bucle. Después alinearía canonical, enlaces internos y sitemap con ese mismo destino.

5. WAF, CSRF, reCAPTCHA y caché

Puedes poner Cloudflare delante de Rails, pero no esperaría a posicionar para revisar seguridad. Si hay componentes sin soporte, el WAF complementa la actualización.

Empezaría con caché de estáticos y exclusiones claras para login, administración, respuestas personalizadas y formularios con tokens de sesión. Evitaría un Cache Everything global: compartir HTML con un token CSRF entre visitantes puede romper formularios o exponer contenido de otra sesión.

Mantendría la protección CSRF de Rails y la validación de reCAPTCHA en el servidor. Si algo falla al activar el proxy, revisaría cookies, caché, protocolo y reglas concretas antes de desactivar esas validaciones.

También comprobaría HTTPS hasta el origen, sin modo Flexible; que Rails reciba el host/protocolo correctos a través de proxies de confianza; y que la IP del cliente se obtenga de cabeceras confiables, no de cualquier cabecera enviada por el visitante. Si el WAF debe proteger todo el tráfico web, hay que controlar también el acceso directo al origen.

Probaría navegación y envío de formularios con dos sesiones independientes, sesión iniciada/cerrada, reCAPTCHA y rastreo de las páginas públicas. Las excepciones del WAF se ajustan sobre bloqueos comprobados, no desactivándolo entero.

Lo haría por cambios pequeños en un entorno de pruebas: primero generación de URLs y redirecciones, después marcado por tipo de página y por último reglas de proxy/caché. Así puedes comprobar cada efecto y revertirlo sin mezclar causas.

Te dejo las referencias para contrastarlo con la agencia:

Escape JSON en Rails:

Configuración de sitemap_generator:

Definición de sameAs:

Canonicalización y redirecciones:

Caché, sesiones y CSRF con Cloudflare: