Ruby on Rails: é possível modificar o SEO pelo frontend?

Olá, betas:

Alguém poderia me dar uma mão com Ruby?

Estou trabalhando em um site desenvolvido com Ruby e preciso entender até que ponto é possível intervir no framework, especialmente em dois aspectos:

• modificar a arquitetura e a estrutura de determinadas páginas;
• adicionar ou modificar dados estruturados (Schema.org / JSON-LD) em páginas de serviços.

Minha dúvida principal é: esse tipo de modificação pode ser realizada diretamente pelo frontend ou é necessário intervir no backend / templates do projeto?

Também me interessa conhecer os riscos: conflitos com o framework, problemas durante futuras atualizações, duplicação do código estruturado, erros de renderização, etc.

Se alguém já trabalhou com Ruby ou Ruby on Rails nesse tipo de projeto SEO, eu gostaria muito de conhecer a sua experiência.

Obrigado desde já!

Sim, é possível, mas depende do que você chama de frontend e de como o site está montado. Primeiro, eu confirmaria se ele usa Ruby on Rails: Ruby é a linguagem e nem todos os sites feitos com Ruby utilizam Rails.

Se é uma aplicação Rails que gera o HTML no servidor, para mudar cabeçalhos, blocos de conteúdo, links internos ou metadados, normalmente você trabalharia nas suas views e layouts, dentro de app/views. É a camada de apresentação, embora esses templates sejam executados no servidor. Você não precisa modificar o código do framework para isso.

Se por «arquitetura» você se refere a mudar URLs, criar novas páginas ou modificar qual informação cada uma carrega, então também podem intervir as rotas —config/routes.rb—, os controllers e, dependendo da mudança, os models. Se você só quer reorganizar o conteúdo de uma página existente, não implica necessariamente tocar em todas essas camadas.

Para JSON-LD, minha primeira opção nesse cenário seria gerá-lo a partir dos mesmos dados que a página usa e renderizá-lo por meio de um template parcial ou um helper. Assim, quando você muda um serviço, não precisa manter separadamente o texto visível e uma cópia do Schema em outro lugar.

Você também pode inseri-lo com JavaScript ou Tag Manager; o Google contempla essa possibilidade. Mas é preciso verificar o HTML renderizado: um erro de JavaScript ou uma condição que impeça a execução da tag pode deixar o código fora. Se o Rails serve apenas uma API e o frontend está em React, Vue ou outra tecnologia, seria preciso revisar como esse frontend gera as páginas.

Sobre os riscos que você menciona, eu revisaria isto antes de publicar:

• Qual código existe já e quem o gera: templates, alguma gem ou Tag Manager. Ter vários blocos JSON-LD não é um erro por si só; o problema é duplicar a mesma entidade com dados contraditórios.
• Que as mudanças fiquem no código da aplicação e sejam testadas à parte antes do deploy. Uma atualização do Rails não deveria obrigá-lo a refazer todo o SEO, mas é preciso verificar compatibilidade e renderização.
• Se você mudar URLs, preparar os redirecionamentos e atualizar links internos, canônicas e sitemap.
• Validar o Schema e verificar os tipos compatíveis com os resultados enriquecidos do Google. Que um código Service seja válido não garante um resultado enriquecido nem uma melhora de posições.

Você tem acesso ao repositório e sabe qual versão do Rails e quais templates/frontend usa? Com esse dado e um exemplo concreto da página que você quer mudar, é possível indicar onde intervir.

Deixo as referências oficiais:

Muito obrigado, Carlos, por uma resposta tão completa!


Eu revisei o código-fonte e confirmo que é uma aplicação Ruby on Rails com renderização no servidor: aparece o meta csrf-token, os assets com hash (/assets/application-<hash>.css) do asset pipeline e o campo oculto utf8=✓ nos formulários. Isso e o Bootstrap 4 em versão alfa me fazem pensar em um Rails 5.x ou anterior; vou pedir o Gemfile.lock à agência para confirmar, porque se for isso, já não recebe patches de segurança.


Detalharei o que preciso fazer, caso você possa me confirmar onde intervir:

1. Sitemap: gera URLs com barra dupla (dominio.fr//rota). Suponho que venha de uma concatenação do host com a rota na gem ou na view .builder. Você corrigiria usando os helpers *_url ou ajustando o default_host?
2. JSON-LD por tipo de página: agora não há nenhum JSON-LD, apenas um bloco RDFa antigo de data-vocabulary.org no footer, que quero eliminar. Minha ideia é um content_for :json_ld em cada view, gerado a partir do model, e um yield :json_ld no layout: RealEstateAgent global com um @id fixo, RealEstateListing com Offer nas fichas (com availability InStock ou SoldOut conforme o estado do bem no banco de dados), ItemList na listagem, Article nas notícias e BreadcrumbList. Você acha que é a abordagem correta em Rails, principalmente para escapar bem o JSON?
3. Entidade: quero reconciliar a entidade com pelo menos cinco sameAs e desambiguar algumas páginas sobre grupos empresariais, com um about para a Organization correspondente.
4. URLs com slug + ID: vi no Search Console variantes do tipo /noticias/texto-qualquer-35 que respondem 200. Parece que o controller busca apenas pelo ID e ignora o slug. Você recomendaria um redirecionamento 301 no controller quando o slug não coincide com o canônico?
5. Segurança: se o site começar a posicionar em buscas transacionais, pretendo colocar um WAF na frente (tipo Cloudflare). Alguma precaução com Rails, por exemplo com o token CSRF, o reCAPTCHA ou o cache?

Obrigado novamente!

Obrigado a você! 🙂 Com o que descreve já é possível concretizar bastante. Sua abordagem está boa, com alguns detalhes para que as mudanças de SEO não criem problemas de URLs, renderização ou sessões.

Primeiro, esses indícios são compatíveis com Rails, mas não permitem datar a versão: uma aplicação atualizada pode conservar templates e dependências antigas. O Gemfile.lock lhe dará uma referência muito mais confiável; convém contrastá-la com o que realmente está implantado. Se for confirmado Rails 5.x, está fora da manutenção oficial e seria necessário planejar sua atualização, sem misturar uma migração grande com todas essas mudanças ao mesmo tempo.

1. Sitemap e barras duplas

Eu corrigiria onde as URLs são geradas, depois de localizar a concatenação concreta. Não daria como certo que a causa é default_host sem ver esse código.

Se usa a gem sitemap_generator, revisaria config/sitemap.rb: default_host com a URL base HTTPS, sem barra final, e as rotas geradas com os helpers *_path que são passados para add. Se é uma view .builder própria, preferiria os helpers *_url, com host e protocolo de produção configurados explicitamente quando forem executados fora de uma requisição web.

São duas formas de construir a URL; não concatenaria novamente o host na frente de um helper que já retorna uma URL completa. Tampouco faria uma substituição global de barras duplas, porque poderia estragar https://.

Depois regeneraria o XML e verificaria se suas URLs são as canônicas, respondem 200 e coincidem com os links internos. Se as variantes com barra dupla já existem publicamente e representam a mesma página, adicionaria um redirecionamento permanente para a correta, sem cadeias. Arrumar apenas o sitemap não elimina essas variantes.

2. JSON-LD, content_for e escape

Sim, content_for :json_ld nas views e yield :json_ld no layout é uma abordagem válida. Teria cuidado com a ordem: o bloco tem que estar definido antes que o layout o emita. Para mantê-lo, construiria os dados através de um helper ou presenter que leia os modelos, e deixaria a view encarregada de renderizá-los.

Para o escape, dentro da tag script de tipo application/ld+json, o padrão ERB é:

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

Aqui datos_schema é o Hash/Array que você constrói com os campos públicos que quer marcar. Primeiro é serializado para JSON válido; depois json_escape protege caracteres que poderiam fechar a tag script. raw é aplicado ao resultado escapado. Não usaria .html_safe diretamente sobre texto de usuários nem despejaria um modelo completo com dados privados. Este padrão também está documentado no Rails 5.2, embora você deva contrastá-lo com a versão real do projeto.

A distribuição que propõe faz sentido: RealEstateAgent com um @id estável; RealEstateListing para a ficha, com sua Offer; ItemList para a listagem, Article para notícias e BreadcrumbList para as migalhas. Distinguiria a ficha do imóvel físico e conectaria as entidades através de @id, usando propriedades válidas para cada tipo. availability vai em Offer e deve refletir o estado real que o visitante também vê.

Pode conectar as entidades por @id, em um ou vários blocos. Não é obrigatório reunir tudo em um único script. Ao mudar o estado do imóvel, invalide também o cache da ficha para que a marcação não continue oferecendo algo vendido.

Substituiria a marcação data-vocabulary.org obsoleta, conservando o conteúdo visível do footer que seja necessário. E validaria duas coisas distintas: o vocabulário com Schema Markup Validator e a elegibilidade dos tipos que o Google admite com seu teste de resultados enriquecidos. Um RealEstateListing válido não garante um resultado especial no Google.

3. Entidades e sameAs

Não há um mínimo de cinco sameAs. Colocaria apenas referências que identifiquem inequivocamente essa mesma entidade: perfis oficiais ou fichas confiáveis, se existirem. Não preencheria a lista com diretórios duvidosos para alcançar uma quantidade.

about para a Organization correspondente encaixa se essa página realmente trata sobre ela. Manteria @id distintos para a agência, cada grupo empresarial e cada imóvel. Compartilhar nome ou pertencer ao mesmo grupo não torna duas sociedades a mesma entidade. Essa coerência ajuda a descrevê-las; não garante por si só sua reconciliação no Google.

4. Slug + ID e redirecionamento

Sim: se várias URLs representam exatamente a mesma notícia, redirecionaria as variantes para sua URL canônica. Faria isso na ação de leitura, depois de carregar o registro e verificar se é público e acessível, gerando o destino com o helper e o slug canônico do próprio registro.

Compararia a rota recebida com essa rota canônica; não construiria o destino com um host ou uma URL fornecidos pelo visitante. Para GET/HEAD, um 301 é adequado. Não estenderia essa regra indiscriminadamente para formulários ou requisições POST.

O teste seria: slug correto retorna 200; slug inventado com ID válido retorna um único redirecionamento para a notícia correta; ID inexistente retorna 404; e não aparece nenhum loop. Depois alinharia canonical, links internos e sitemap com esse mesmo destino.

5. WAF, CSRF, reCAPTCHA e cache

Pode colocar Cloudflare na frente do Rails, mas não esperaria para posicionar para revisar a segurança. Se há componentes sem suporte, o WAF complementa a atualização.

Começaria com cache de estáticos e exclusões claras para login, administração, respostas personalizadas e formulários com tokens de sessão. Evitaria um Cache Everything global: compartilhar HTML com um token CSRF entre visitantes pode quebrar formulários ou expor conteúdo de outra sessão.

Manteria a proteção CSRF do Rails e a validação de reCAPTCHA no servidor. Se algo falhar ao ativar o proxy, revisaria cookies, cache, protocolo e regras concretas antes de desativar essas validações.

Também verificaria HTTPS até a origem, sem modo Flexible; que o Rails receba o host/protocolo corretos através de proxies de confiança; e que o IP do cliente seja obtido de cabeçalhos confiáveis, não de qualquer cabeçalho enviado pelo visitante. Se o WAF deve proteger todo o tráfego web, é preciso controlar também o acesso direto à origem.

Testaria navegação e envio de formulários com duas sessões independentes, sessão iniciada/encerrada, reCAPTCHA e rastreamento das páginas públicas. As exceções do WAF são ajustadas sobre bloqueios comprovados, não desativando-o inteiro.

Faria isso por pequenas mudanças em um ambiente de testes: primeiro geração de URLs e redirecionamentos, depois marcação por tipo de página e por último regras de proxy/cache. Assim você pode verificar cada efeito e revertê-lo sem misturar causas.

Deixo as referências para contrastar com a agência:

Escape JSON no Rails:

Configuração de sitemap_generator:

Definição de sameAs:

Canonicalização e redirecionamentos:

Cache, sessões e CSRF com Cloudflare: