14 MINUTOS DE LEITURA
Multi Site do Framer: site e app no mesmo domínio
Por:
Henrique Sabino
O Multi Site do Framer é o recurso de hospedagem que junta vários projetos e sites externos sob um único domínio, por regras de rewrite: o site em empresa.com, o blog em empresa.com/blog e o app em empresa.com/app. Ele vem no add-on Advanced Hosting, de US$ 200 por mês, ou no plano Enterprise.
Quem tem site e produto precisa decidir onde cada um mora no domínio. No portfólio da Wama há casos assim: a Milhas Pix, com plataforma SaaS, sistema de gestão, site e landing pages, e a Visor, com SaaS, sistema, app e blog. Antes de escolher o endereço, vale entender o que separa a página pública da área logada.
Os guias em português sobre subdomínio e subdiretório vêm de agências de SEO e não dizem quanto custa nem como se configura. Este guia olha pelo lado de quem paga a conta: quando o subdomínio resolve de graça, quando a subpasta vale o add-on e o que costuma quebrar. Para quem vende software, a decisão começa em o que entra no site público de um produto por assinatura.
O que é o Multi Site do Framer?
O Multi Site é a área de configuração em que o dono do site cria regras de rewrite. Um rewrite entrega o conteúdo de outro lugar mantendo o endereço que o visitante digitou, ao contrário do redirecionamento, que troca a URL no navegador. O destino pode ser outro projeto do Framer ou um site externo, como a documentação ou o aplicativo da empresa.
Segundo a ajuda do Framer sobre Multi Site, atualizada em 15 de setembro de 2026, as regras saíram do painel de domínios e agora ficam em Site Settings, Hosting, Multi Site. Cada regra tem um caminho, como /blog ou /blog/*, e um destino. Elas rodam na ordem da lista e só valem depois de publicar o projeto.
A mesma página lista quatro usos: migrar de outra plataforma aos poucos, dividir um site grande em projetos menores, juntar loja, documentação ou aplicativo ao site e separar seções por time. Um detalhe pega desprevenido: quando uma página do projeto e uma regra usam o mesmo caminho, a regra vence.
Subdomínio ou subpasta: o que o Google diz?
O Google diz que trata os dois formatos da mesma maneira. Em maio de 2018, John Mueller, analista do Google, afirmou em sessão pública que subdomínio e subdiretório são vistos igual, segundo o Search Engine Journal. A recomendação dele foi manter junto o que é o mesmo site e usar subdomínio quando o conteúdo é de fato diferente.
Um guia de uma agência de SEO, publicado em novembro de 2025, sustenta o contrário: que o Google enxerga subdomínio e subdiretório de formas bem diferentes. A documentação oficial registra uma diferença concreta, e ela é pequena. A página do Google sobre nomes de site, atualizada em 10 de dezembro de 2025, informa que o nome exibido na busca vale para domínio e subdomínio, e que subdiretório não tem nome próprio.
Na prática, o critério é de conteúdo. Blog, central de ajuda e páginas de campanha são o mesmo site, e a recomendação de mantê-los juntos aponta para a subpasta. O painel logado ninguém procura no Google, então app.empresa.com atende sem custo. Outro assunto é dar domínio próprio para cada cliente dentro do produto, que se resolve no software, e não no site.
Quanto custa pôr site e app no mesmo domínio?
Com subdomínio, nada além do plano: basta apontar o DNS. Com subpasta, o custo é o Advanced Hosting. A página de preços do Framer, lida em 4 de outubro de 2026 na cobrança anual, mostra o add-on a US$ 200 por mês sobre o plano Pro, de US$ 30, com no máximo seis rewrites. No Enterprise ele já vem incluso.
Caminho | Exigência | Custo mensal na página oficial |
|---|---|---|
Subdomínio apontado por DNS (app.empresa.com) | Registro de DNS para o servidor do app | Sem add-on |
Subpasta com Multi Site (empresa.com/app) | Advanced Hosting ou Enterprise | US$ 200 sobre o Pro, até 6 rewrites |
Blog ou seção em outro projeto da plataforma | Advanced Hosting e plano pago no projeto de destino | US$ 200 mais o plano do segundo projeto |
O add-on não tem período de teste, segundo a página de hospedagem do Framer. Além dos rewrites, ele libera cabeçalhos de segurança personalizados, até 500 arquivos estáticos e o bloqueio por país que usa o mesmo add-on.
Para manter um proxy próprio, como o Cloudflare, na frente do site, as páginas oficiais divergem sobre o plano. A ajuda do Framer sobre proxy com Cloudflare, atualizada em 30 de setembro de 2026, aceita o Pro com Advanced Hosting ou o Enterprise. O guia de integração com site existente, de 15 de setembro, pede Enterprise. Vale confirmar com o suporte antes de assinar.
Nos projetos da Wama, o site sai quase sempre no plano Pro, é transferido para a conta do cliente e a assinatura fica no cartão dele. Um add-on entra nessa mesma fatura, em dólar, sem repasse. Por isso a conta precisa ser feita antes, a partir de o que o plano Pro cobre antes de qualquer add-on.
O que quebra quando o app vai para a subpasta
O rewrite entrega o que a origem manda, sem corrigir nada no caminho. A ajuda oficial do Multi Site lista o que precisa de ajuste antes de publicar a regra:
Caminho base. Um site externo que carrega scripts, fontes e imagens a partir da raiz aparece quebrado em /docs. A correção é configurar o caminho base na aplicação de origem e publicá-la de novo.
Cookies. O rewrite repassa os cookies do site ao destino externo, e o destino também pode gravar cookies. A orientação é só reescrever para serviços em que a empresa confia.
Senha. A proteção por senha vale só para o projeto principal. Ligada só no projeto de destino, ela não cobre o conteúdo servido pela regra.
Medição. Analytics, testes A/B e funis da plataforma enxergam apenas o projeto principal. As páginas servidas por rewrite precisam ser medidas na origem.
CMS. O caminho da coleção tem de ser o mesmo na regra e no projeto de origem. Vale rever como as coleções do CMS geram as páginas do blog antes de separar os projetos.
Endereço canônico. Cada projeto declara como canônico o domínio final. Os sitemaps das origens são combinados automaticamente.
A origem externa também precisa responder em HTTPS. Tudo isso se confere no endereço de staging, antes de qualquer mudança no DNS.
Migração para o Framer página por página
A migração gradual usa uma única regra curinga. Segundo o guia do Framer para migrar página por página, atualizado em 15 de setembro de 2026, a regra /* aponta para o site antigo com a opção Match pages first ligada. A plataforma entrega a página que já existe no projeto novo e, quando ela ainda não existe, busca a versão antiga.
Criar o projeto, publicar e conectar o domínio, sem alterar o DNS ainda.
Criar a regra curinga /* para o site antigo, com Match pages first ligado.
Criar uma regra separada para a página inicial, com a opção desligada, até a nova home ficar pronta.
Publicar e conferir tudo no domínio de staging.
Apontar o DNS para o projeto novo.
Publicar as páginas novas com os mesmos caminhos das antigas.
Remover a regra curinga quando a última página migrar.
A condição do método é manter os endereços. Na migração de WordPress para Framer que a Wama conduziu num site institucional com centenas de páginas e blog grande, o que deu errado incluiu endereços antigos mal organizados: URLs duplicadas, com parâmetro e sem padrão. Em caso assim, a limpeza vem antes da primeira regra. O caminho alternativo é a migração feita de uma vez, com todos os redirecionamentos.
Como decidir entre subdomínio, Multi Site e um projeto só
A decisão cabe em quatro situações, da mais barata para a mais cara:
Site e blog no mesmo projeto. O CMS gera as páginas em /blog e nenhum add-on é necessário.
Produto com login. O aplicativo fica em subdomínio, apontado por DNS, sem custo extra de hospedagem.
Documentação, ajuda ou blog em outra ferramenta, que precisam aparecer como parte do site. É o caso do Multi Site, com a conta de US$ 200 por mês.
Site grande saindo de outra plataforma. O Multi Site entra durante a migração, e a regra curinga sai quando a última página estiver no ar.
Na Wama, área logada e conteúdo restrito ficam fora do site em Framer: viram projeto de produto digital, feito pelo mesmo estúdio com outra stack. A escolha entre subdomínio e subpasta pertence ao escopo, e vale levá-la à primeira conversa com quem desenha e configura o projeto no Framer.
Perguntas frequentes sobre o Multi Site do Framer
O Multi Site do Framer funciona no plano Basic?
Não. A página de preços do Framer, lida em 4 de outubro de 2026, lista o Advanced Hosting como add-on do plano Pro, a US$ 200 por mês, e como item incluso no Enterprise. No Basic, a saída para separar site e aplicativo é o subdomínio, que só depende de apontar o DNS.
Subdomínio prejudica o SEO do site?
O Google afirma que trata subdomínio e subdiretório da mesma forma, em declaração de John Mueller de maio de 2018. A orientação dele é manter no mesmo endereço o que faz parte do mesmo site. Para um aplicativo logado, que fica fora da busca, o subdomínio resolve sem custo e sem perda.
Quantos rewrites o Advanced Hosting permite?
Até seis, segundo a página de preços do Framer. As regras rodam na ordem em que aparecem na lista do Multi Site, e uma regra com curinga, como /blog/*, cobre todas as páginas abaixo daquele caminho. Quem precisa de mais destinos encontra limites sob consulta no plano Enterprise.
O Analytics do Framer mede as páginas servidas por rewrite?
Não. A ajuda oficial informa que Analytics, testes A/B e funis acompanham apenas o projeto principal, sem incluir visitas nem eventos das páginas servidas por rewrite. Para ter a jornada completa, a medição precisa existir também na origem, seja outro projeto, a documentação ou o aplicativo.
Preciso do Multi Site para ter um blog em /blog?
Não, quando o blog vive no mesmo projeto do site: o CMS do Framer publica as páginas em /blog sem add-on. O Multi Site só entra se o blog estiver em outro projeto ou em outra ferramenta e precisar aparecer no mesmo domínio, como parte do site principal.
Se a sua empresa tem site em Framer e produto, e precisa decidir onde cada um mora antes de construir, fale com a Wama sobre o seu projeto.
