RFP — Portal, Ecossistema Digital e Plataforma
Pública da Marca EVO
Versão: 1.0
Data: junho/2026
Empresa: Brasil TecPar / EVO Digital
Documento: Escopo orientativo para contratação de parceiro estratégico de design, UX,
tecnologia, conteúdo, SEO, GEO, segurança, integrações e implantação do ecossistema
digital público da EVO.
1. Sumário executivo
A EVO será a nova marca nacional da Brasil TecPar, partindo de aproximadamente 1,8 milhão
de acessos, com direcionamento estratégico para atingir 5 milhões de acessos em 3 anos,
presença em múltiplos estados, operação residencial, pequenas e médias empresas,
corporate, governo, wholesale, ISPs, OTTs e serviços digitais.
Este projeto não deve ser tratado como “criação de site institucional”. O objetivo é construir o
front door digital da companhia: uma plataforma pública, indexável, segura, performática,
escalável, integrada, preparada para SEO, GEO, IA, jornada digital, atendimento, geração de
demanda, relacionamento, transparência e suporte à expansão nacional da marca.
A empresa contratada deverá entregar um ecossistema digital completo, com arquitetura de
informação robusta, páginas públicas estáticas e indexáveis para todas as frentes relevantes
do negócio, design system próprio, CMS headless, componentes reutilizáveis, stack
moderna, integração com sistemas transacionais externos e governança editorial e técnica.
A diretriz central é:
evo.digital deve ser o cérebro público, informativo, indexável, institucional e
comercial da marca.
Subdomínios devem ser usados para sistemas, portais, login, contratação, APIs,
atendimento, parceiros e operação.
2. Contexto estratégico

-- 1 of 81 --

2.1. Ambição da marca
A EVO nasce para consolidar uma operação nacional de conectividade e tecnologia, reunindo
infraestrutura, atendimento próximo, presença regional, soluções digitais e escala
corporativa.
A marca precisa comunicar simultaneamente:
Confiança;
Proximidade;
Inovação;
Escala nacional;
Capacidade técnica;
Presença local;
Evolução;
Solidez institucional;
Plataforma digital;
Atendimento humano;
Capacidade para consumidores, empresas, governo e operadoras.
2.2. Tagline institucional
EVO — Conectando o que Vem Depois
2.3. Mercados atendidos
A arquitetura pública deve organizar o ecossistema em cinco grandes mercados:
1. Para Você — clientes residenciais;
2. Para Empresas — pequenas e médias empresas;
3. Corporate — grandes empresas e operações críticas;
4. Governo — municipal, estadual, federal, empresas públicas e autarquias;
5. Operadoras, ISPs e OTTs — wholesale, carriers, ISPs, OTTs, interconexão, transporte,
peering, colocation e serviços internacionais.
2.4. Princípio de linguagem

-- 2 of 81 --

Evitar linguagem interna como “B2C”, “B2B”, “B2G”, “B2W” ou “B2S” no site público. Esses
termos podem existir nos bastidores, mas a arquitetura de navegação deve falar a linguagem
do cliente:
Para Você;
Para Empresas;
Corporate;
Governo;
Operadoras, ISPs e OTTs.
3. Objetivos do projeto
3.1. Objetivo geral
Construir o portal público e a arquitetura digital da EVO, com escopo capaz de suportar o
lançamento da nova marca, a migração das marcas legadas, a expansão nacional, o
crescimento orgânico, a geração de demanda, a integração com portais transacionais e a
consolidação da empresa como plataforma nacional de conectividade e tecnologia.
3.2. Objetivos específicos
O projeto deverá:
1. Criar o portal público principal evo.digital ;
2. Definir e implementar a arquitetura de informação completa;
3. Criar páginas indexáveis para mercados, soluções, produtos, setores, programas,
atendimento, confiança, institucional, cidades e conteúdo;
4. Integrar o site com APIs de ofertas, produtos, disponibilidade e conteúdos dinâmicos;
5. Integrar CTAs para assine.evo.digital , contrate.empresas.evo.digital ,
cliente.evo.digital , indique.evo.digital , parceiros.evo.digital e demais
sistemas;
6. Implementar SEO técnico, SEO local, GEO e estrutura compatível com IA;
7. Implantar CMS headless com governança editorial;
8. Criar design system EVO para aplicações digitais;
9. Garantir performance, segurança, acessibilidade e observabilidade;

-- 3 of 81 --

10. Entregar documentação técnica, operacional, editorial e de governança;
11. Criar base para evolução futura do app, portais, APIs, wholesale, status page,
documentação técnica e relacionamento com clientes;
12. Evitar uma entrega básica, genérica, frágil ou dependente de fornecedor sem
governança.
4. Princípios inegociáveis
4.1. Site público como ativo estratégico
O portal evo.digital deve ser tratado como ativo estratégico da companhia. Ele será ponto
de entrada para:
Cliente residencial;
Pequenas e médias empresas;
Grandes empresas;
Governo;
Operadoras e ISPs;
Investidores;
Imprensa;
Fornecedores;
Parceiros;
Colaboradores;
Candidatos;
Comunidades locais;
Buscadores;
Mecanismos de IA;
Auditorias;
Órgãos reguladores;
Potenciais empresas adquiridas.

-- 4 of 81 --

4.2. Conteúdo indexável no domínio principal
Tudo que precisa ranquear, ser encontrado, ser citado, ser compreendido por IA ou reforçar
autoridade de marca deve estar em:
https://evo.digital/...
Exemplos:
/evo.digital/para-voce/internet
/evo.digital/empresas/internet-conectividade
/evo.digital/corporate/cloud-data-center
/evo.digital/governo/cidades-inteligentes
/evo.digital/operadoras-isps-otts/peering
/evo.digital/programas/indique
/evo.digital/confianca/canais-oficiais
/evo.digital/cidades/sao-paulo/barueri
4.3. Subdomínios para sistemas
Subdomínios devem ser usados para sistemas, portais, login, operação, contratação, API,
área logada e ferramentas.
Exemplos:
assine.evo.digital
contrate.empresas.evo.digital
cliente.evo.digital
indique.evo.digital
parceiros.evo.digital
fornecedores.evo.digital
wholesale.evo.digital
docs.evo.digital
api.evo.digital
status.evo.digital
4.4. Separação entre conteúdo, catálogo e transação
A arquitetura deve separar:
Conteúdo editorial/institucional;
Catálogo de produtos e ofertas;
Motor de disponibilidade e elegibilidade;

-- 5 of 81 --

Contratação/e-commerce;
Área logada;
Atendimento;
APIs;
Analytics.
O site não deve ser o sistema de contratação. O e-commerce não deve ser o site
institucional. O CMS não deve ser o motor de preço e elegibilidade.
4.5. Fonte da verdade comercial
A recomendação é que exista uma camada canônica chamada, por exemplo, EVO Offer Hub
/ Product Catalog API, responsável por expor:
Produtos;
Planos;
Ofertas;
Bundles;
Preços;
Promoções;
Vigência;
Canais;
Segmentos;
Disponibilidade;
Elegibilidade;
Regras comerciais;
Textos comerciais padronizados;
Selos e destaques.
Tanto o site quanto os e-commerces devem consumir essa camada.
5. Arquitetura digital recomendada

-- 6 of 81 --

5.1. Domínio principal
evo.digital
Função:
Marca;
Conteúdo;
SEO;
GEO;
IA;
Páginas institucionais;
Páginas comerciais;
Páginas por mercado;
Páginas por solução;
Páginas por setor;
Páginas por cidade;
Páginas de programas;
Confiança e segurança;
Migração de marcas;
Atendimento informativo;
Geração de demanda.
5.2. Sistemas e subdomínios principais
Subdomínio 	Função 	Tipo 	Indexar?
assine.evo.digital
E-commerce
aberto para
residencial e
PME simples
Transacional Não indexar
checkout
Portal/e-
commerce

-- 7 of 81 --

contrate.empresas.evo.digital 	logado
empresarial
Transacional/logado 	Não
cliente.evo.digital 	Área do cliente 	Logado 	Não
ajuda.evo.digital
Central de
ajuda e base
de
conhecimento
Público + suporte 	Parcial
atendimento.evo.digital
Canais oficiais
de
atendimento
Público Sim ou
redirecionar
status.evo.digital Status de rede
e serviços Público 	Sim
indique.evo.digital Programa de
indicação Sistema/formulário 	Parcial
parceiros.evo.digital Portal de
parceiros Sistema/formulário/logado 	Parcial
fornecedores.evo.digital Portal de
fornecedores Sistema/formulário/logado 	Parcial
wholesale.evo.digital
Portal para
operadoras,
ISPs e OTTs
Público/técnico/logado 	Parcial
docs.evo.digital Documentação
técnica Público/técnico 	Sim
api.evo.digital 	APIs 	Técnico
Não, exceto
docs
públicas
auth.evo.digital 	Autenticação 	Sistema 	Não
id.evo.digital 	Identidade/SSO 	Sistema 	Não
privacidade.evo.digital Portal de
privacidade Público/sistema 	Sim
seguranca.evo.digital
Central de
segurança e Público 	Sim

-- 8 of 81 --

antifraude
trust.evo.digital Trust center
corporativo Público/B2B 	Sim
ouvidoria.evo.digital 	Ouvidoria 	Público/formulário 	Sim
lojas.evo.digital Localizador de
lojas Público 	Sim
carreiras.evo.digital 	Carreiras 	Público/sistema 	Sim
imprensa.evo.digital 	Imprensa 	Público 	Sim
ri.evo.digital Relações com
investidores Público 	Sim
brand.evo.digital 	Brand center 	Controlado 	Parcial
design.evo.digital 	Design system 	Controlado Não ou
parcial
5.3. Subdomínios defensivos e de redirecionamento
Reservar para proteção, redirecionamento e evolução futura:
www.evo.digital
internet.evo.digital
fibra.evo.digital
movel.evo.digital
tv.evo.digital
streaming.evo.digital
telefone.evo.digital
camera.evo.digital
cameras.evo.digital
casaconectada.evo.digital
cloud.evo.digital
datacenter.evo.digital
cyber.evo.digital
iot.evo.digital
voz.evo.digital
sdwan.evo.digital
mpls.evo.digital
conectividade.evo.digital
carrier.evo.digital
operadoras.evo.digital
peering.evo.digital

-- 9 of 81 --

lookingglass.evo.digital
lg.evo.digital
noc.evo.digital
as53062.evo.digital
interconexao.evo.digital
transitoip.evo.digital
colocation.evo.digital
beneficios.evo.digital
recompensas.evo.digital
embaixadores.evo.digital
afiliados.evo.digital
revendas.evo.digital
credenciados.evo.digital
condominios.evo.digital
imobiliarias.evo.digital
construtoras.evo.digital
representantes.evo.digital
franquias.evo.digital
marketplace.evo.digital
segunda-via.evo.digital
boleto.evo.digital
pix.evo.digital
pagamento.evo.digital
fatura.evo.digital
suporte.evo.digital
compliance.evo.digital
etica.evo.digital
canalconfidencial.evo.digital
sustentabilidade.evo.digital
transparencia.evo.digital
universidade.evo.digital
materiais.evo.digital
intranet.evo.digital
colaboradores.evo.digital
amigo.evo.digital
blink.evo.digital
avato.evo.digital
ligga.evo.digital
agora.evo.digital
bemvindo.evo.digital
sou.evo.digital
5.4. Regra para produtos em subdomínios
Produtos devem ter páginas públicas em evo.digital/... .
Subdomínios de produtos devem ser usados apenas quando houver:

-- 10 of 81 --

1. Portal logado;
2. Console de serviço;
3. Documentação técnica;
4. API;
5. Ambiente operacional;
6. Redirecionamento defensivo.
Exemplo correto para Cloud:
Evitar:
cloud.servicos.evo.digital
produto-cloud.evo.digital
hotsitecloud.evo.digital
6. Mapa completo do site público
A árvore abaixo é propositalmente ampla. A empresa contratada deverá propor priorização
de lançamento, mas a arquitetura deve ser planejada para comportar todo o ecossistema.
evo.digital
├── /
│
├── para-voce
│ 	├── internet
│ 	│ 	├── planos-de-internet
│ 	│ 	├── internet-fibra
│ 	│ 	├── wifi-inteligente
│ 	│ 	├── internet-gamer
│ 	│ 	├── internet-para-home-office
│ 	│ 	├── internet-para-streaming
│ 	│ 	├── internet-para-condominios
│ 	│ 	├── internet-em-apartamento
│ 	│ 	├── cobertura
evo.digital/corporate/cloud-data-center 	# página pública, SEO e GEO
cloud.evo.digital 	# console/portal de cloud, se existir
docs.evo.digital/cloud 	# documentação técnica
contrate.empresas.evo.digital/cloud 	# contratação/expansão

-- 11 of 81 --

│ 	│ 	└── consultar-disponibilidade
│ 	│
│ 	├── movel
│ 	│ 	├── planos-moveis
│ 	│ 	├── chip
│ 	│ 	├── esim
│ 	│ 	├── portabilidade
│ 	│ 	├── roaming
│ 	│ 	├── internet-movel
│ 	│ 	└── familia
│ 	│
│ 	├── telefone
│ 	│ 	├── telefone-fixo
│ 	│ 	├── telefone-ilimitado
│ 	│ 	└── portabilidade-de-telefone
│ 	│
│ 	├── tv-streaming
│ 	│ 	├── tv
│ 	│ 	├── streaming
│ 	│ 	├── canais
│ 	│ 	├── combos-com-streaming
│ 	│ 	└── entretenimento
│ 	│
│ 	├── servicos-digitais
│ 	│ 	├── protecao-digital
│ 	│ 	├── antivirus
│ 	│ 	├── backup
│ 	│ 	├── apps
│ 	│ 	├── suporte-digital
│ 	│ 	└── beneficios-digitais
│ 	│
│ 	├── camera
│ 	│ 	├── camera-residencial
│ 	│ 	├── monitoramento-residencial
│ 	│ 	├── camera-com-app
│ 	│ 	└── seguranca-para-casa
│ 	│
│ 	├── casa-conectada
│ 	│ 	├── automacao-residencial
│ 	│ 	├── dispositivos-inteligentes
│ 	│ 	├── casa-inteligente
│ 	│ 	└── solucoes-para-familia
│ 	│
│ 	├── combos
│ 	│ 	├── internet-movel
│ 	│ 	├── internet-tv-streaming
│ 	│ 	├── internet-camera

-- 12 of 81 --

│ 	│ 	├── internet-servicos-digitais
│ 	│ 	└── internet-casa-conectada
│ 	│
│ 	├── promocoes
│ 	├── beneficios
│ 	├── indique-e-ganhe
│ 	└── assine-agora
│
├── empresas
│ 	├── internet-conectividade
│ 	│ 	├── internet-empresarial
│ 	│ 	├── internet-para-pequenas-empresas
│ 	│ 	├── internet-para-medias-empresas
│ 	│ 	├── link-dedicado-empresarial
│ 	│ 	├── wifi-empresarial
│ 	│ 	├── rede-para-filiais
│ 	│ 	└── consulta-de-cobertura-empresarial
│ 	│
│ 	├── voz
│ 	│ 	├── telefonia-empresarial
│ 	│ 	├── pabx
│ 	│ 	├── telefone-ip
│ 	│ 	├── numero-0800
│ 	│ 	└── atendimento-telefonico
│ 	│
│ 	├── mobilidade
│ 	│ 	├── planos-moveis-empresariais
│ 	│ 	├── chips-corporativos
│ 	│ 	├── esim-empresarial
│ 	│ 	├── gestao-de-linhas
│ 	│ 	└── mobilidade-para-equipes
│ 	│
│ 	├── monitoramento
│ 	│ 	├── cameras-para-empresas
│ 	│ 	├── cftv
│ 	│ 	├── monitoramento-remoto
│ 	│ 	└── seguranca-patrimonial
│ 	│
│ 	├── produtividade-gestao
│ 	│ 	├── ferramentas-de-produtividade
│ 	│ 	├── colaboracao
│ 	│ 	├── email-corporativo
│ 	│ 	├── armazenamento
│ 	│ 	└── gestao-digital
│ 	│
│ 	├── seguranca
│ 	│ 	├── seguranca-digital-para-empresas

-- 13 of 81 --

│ 	│ 	├── firewall
│ 	│ 	├── protecao-de-dispositivos
│ 	│ 	├── backup-empresarial
│ 	│ 	└── suporte-seguro
│ 	│
│ 	├── servicos-gerenciados
│ 	│ 	├── ti-gerenciada
│ 	│ 	├── suporte-tecnico
│ 	│ 	├── monitoramento-de-ambiente
│ 	│ 	└── gestao-de-servicos
│ 	│
│ 	├── presenca-digital
│ 	│ 	├── site-para-empresa
│ 	│ 	├── dominio
│ 	│ 	├── email-profissional
│ 	│ 	├── marketing-digital
│ 	│ 	└── loja-online
│ 	│
│ 	├── planos
│ 	├── combos
│ 	├── contrate-para-sua-empresa
│ 	└── fale-com-consultor
│
├── corporate
│ 	├── conectividade
│ 	│ 	├── internet-dedicada
│ 	│ 	├── mpls
│ 	│ 	├── sd-wan
│ 	│ 	├── ethernet
│ 	│ 	├── interconexao
│ 	│ 	├── transito-ip
│ 	│ 	├── transporte-optico
│ 	│ 	├── conectividade-internacional
│ 	│ 	├── redes-privativas
│ 	│ 	└── conectividade-para-operacoes-criticas
│ 	│
│ 	├── cloud-data-center
│ 	│ 	├── cloud
│ 	│ 	├── cloud-privada
│ 	│ 	├── cloud-publica
│ 	│ 	├── cloud-hibrida
│ 	│ 	├── colocation
│ 	│ 	├── data-center
│ 	│ 	├── backup
│ 	│ 	├── disaster-recovery
│ 	│ 	├── storage
│ 	│ 	├── servidores

-- 14 of 81 --

│ 	│ 	└── multicloud
│ 	│
│ 	├── tecnologia-da-informacao
│ 	│ 	├── service-desk
│ 	│ 	├── workplace
│ 	│ 	├── outsourcing-de-ti
│ 	│ 	├── infraestrutura-de-ti
│ 	│ 	├── observabilidade
│ 	│ 	├── automacao
│ 	│ 	├── microsoft
│ 	│ 	└── google
│ 	│
│ 	├── cyber-seguranca
│ 	│ 	├── soc
│ 	│ 	├── xdr
│ 	│ 	├── mdr
│ 	│ 	├── firewall
│ 	│ 	├── sase
│ 	│ 	├── ztna
│ 	│ 	├── pentest
│ 	│ 	├── awareness
│ 	│ 	├── resposta-a-incidentes
│ 	│ 	└── seguranca-gerenciada
│ 	│
│ 	├── voz-colaboracao
│ 	│ 	├── pabx
│ 	│ 	├── sip
│ 	│ 	├── ucaas
│ 	│ 	├── contact-center
│ 	│ 	├── teams-voice
│ 	│ 	├── numero-0800
│ 	│ 	└── telefonia-corporativa
│ 	│
│ 	├── mobilidade
│ 	│ 	├── planos-moveis-corporativos
│ 	│ 	├── esim-corporativo
│ 	│ 	├── gestao-de-dispositivos
│ 	│ 	├── mdm
│ 	│ 	└── mobilidade-corporativa
│ 	│
│ 	├── iot
│ 	│ 	├── internet-das-coisas
│ 	│ 	├── sensores
│ 	│ 	├── telemetria
│ 	│ 	├── rastreamento
│ 	│ 	├── campo-conectado
│ 	│ 	├── industria-conectada

-- 15 of 81 --

│ 	│ 	└── cidades-inteligentes
│ 	│
│ 	├── servicos-digitais
│ 	│ 	├── inteligencia-artificial
│ 	│ 	├── analytics
│ 	│ 	├── dados
│ 	│ 	├── crm
│ 	│ 	├── automacao-de-processos
│ 	│ 	├── experiencia-do-cliente
│ 	│ 	└── plataformas-digitais
│ 	│
│ 	├── servicos-profissionais
│ 	│ 	├── consultoria
│ 	│ 	├── projetos
│ 	│ 	├── implantacao
│ 	│ 	├── arquitetura-de-solucoes
│ 	│ 	├── devops
│ 	│ 	├── transformacao-digital
│ 	│ 	├── sap
│ 	│ 	└── fabrica-de-software
│ 	│
│ 	├── solucoes-por-desafio
│ 	│ 	├── reduzir-custos
│ 	│ 	├── aumentar-disponibilidade
│ 	│ 	├── conectar-filiais
│ 	│ 	├── proteger-dados
│ 	│ 	├── migrar-para-cloud
│ 	│ 	├── modernizar-ti
│ 	│ 	├── monitorar-operacoes
│ 	│ 	└── acelerar-transformacao-digital
│ 	│
│ 	└── fale-com-especialista
│
├── governo
│ 	├── municipal
│ 	├── estadual
│ 	├── federal
│ 	├── empresas-publicas
│ 	├── autarquias
│ 	├── solucoes
│ 	│ 	├── conectividade-publica
│ 	│ 	├── governo-digital
│ 	│ 	├── cidades-inteligentes
│ 	│ 	├── educacao-conectada
│ 	│ 	├── saude-conectada
│ 	│ 	├── seguranca-publica
│ 	│ 	├── data-center-governamental

-- 16 of 81 --

│ 	│ 	├── cyber-seguranca-para-governo
│ 	│ 	├── videomonitoramento-publico
│ 	│ 	└── internet-para-orgaos-publicos
│ 	├── modalidades
│ 	│ 	├── licitacoes
│ 	│ 	├── atas-de-registro
│ 	│ 	├── contratos-publicos
│ 	│ 	├── credenciamento
│ 	│ 	└── parcerias-publicas
│ 	├── documentos
│ 	│ 	├── certidoes
│ 	│ 	├── qualificacoes-tecnicas
│ 	│ 	├── compliance
│ 	│ 	├── seguranca-da-informacao
│ 	│ 	└── sustentabilidade
│ 	└── fale-com-especialista-em-governo
│
├── operadoras-isps-otts
│ 	├── wholesale
│ 	├── ethernet
│ 	├── mpls
│ 	├── interconexao
│ 	├── transito-ip
│ 	├── peering
│ 	├── transporte-optico
│ 	├── colocation
│ 	├── trafego-de-voz
│ 	├── conectividade-internacional
│ 	├── backbone
│ 	├── cdn-cache
│ 	├── data-center
│ 	├── mapa-de-rede
│ 	├── politicas-de-peering
│ 	├── as53062
│ 	├── noc
│ 	└── fale-com-wholesale
│
├── setores
│ 	├── agronegocio
│ 	├── educacao
│ 	├── energia
│ 	├── governo
│ 	├── industria
│ 	├── midia-entretenimento
│ 	├── mineracao
│ 	├── saude
│ 	├── financeiro

-- 17 of 81 --

│ 	└── varejo
│
├── programas
│ 	├── indique
│ 	│ 	├── como-funciona
│ 	│ 	├── regulamento
│ 	│ 	├── acompanhar-indicacao
│ 	│ 	├── indique-para-sua-casa
│ 	│ 	├── indique-para-empresas
│ 	│ 	└── indique-para-condominios
│ 	├── beneficios
│ 	├── embaixadores
│ 	├── afiliados
│ 	├── parceiros
│ 	├── revendas
│ 	├── representantes
│ 	├── credenciados
│ 	├── condominios
│ 	├── imobiliarias
│ 	├── construtoras
│ 	├── fornecedores
│ 	├── franquias
│ 	└── marketplace
│
├── atendimento
│ 	├── central-de-ajuda
│ 	├── canais-oficiais
│ 	├── segunda-via
│ 	├── pagamento
│ 	├── negociar-debito
│ 	├── suporte-tecnico
│ 	├── acompanhar-instalacao
│ 	├── acompanhar-atendimento
│ 	├── mudanca-de-endereco
│ 	├── cancelamento
│ 	├── ouvidoria
│ 	├── app-evo
│ 	├── area-do-cliente
│ 	├── lojas
│ 	├── encontre-uma-loja
│ 	├── status-da-rede
│ 	├── perguntas-frequentes
│ 	└── atendimento-acessivel
│
├── lojas
│ 	├── encontre-uma-loja
│ 	├── lojas-por-estado

-- 18 of 81 --

│ 	├── lojas-por-cidade
│ 	├── unidades-evo
│ 	├── atendimento-presencial
│ 	├── agendar-atendimento
│ 	└── seja-um-ponto-parceiro
│
├── cobertura
│ 	├── consultar-cobertura
│ 	├── cobertura-por-estado
│ 	├── cobertura-por-cidade
│ 	├── cobertura-para-empresas
│ 	├── cobertura-para-condominios
│ 	└── solicitar-expansao-de-rede
│
├── cidades
│ 	├── sao-paulo
│ 	├── parana
│ 	├── rio-grande-do-sul
│ 	├── santa-catarina
│ 	├── mato-grosso
│ 	├── goias
│ 	├── minas-gerais
│ 	└── [demais-estados-e-cidades]
│
├── conteudo
│ 	├── blog
│ 	├── noticias
│ 	├── guias
│ 	├── estudos
│ 	├── materiais-ricos
│ 	├── ebooks
│ 	├── webinars
│ 	├── eventos
│ 	├── glossario
│ 	├── comparativos
│ 	├── central-de-conhecimento
│ 	└── newsletter
│
├── novidades
│ 	├── noticias-da-evo
│ 	├── releases
│ 	├── imprensa
│ 	├── midia-kit
│ 	├── comunicados
│ 	└── eventos
│
├── sobre

-- 19 of 81 --

│ 	├── quem-somos
│ 	├── nossa-historia
│ 	├── agora-somos-evo
│ 	├── brasil-tecpar-agora-evo
│ 	├── marcas-que-agora-sao-evo
│ 	├── numeros-da-evo
│ 	├── presenca-nacional
│ 	├── infraestrutura
│ 	├── rede
│ 	├── data-centers
│ 	├── lideranca
│ 	├── governanca
│ 	├── cultura
│ 	├── inovacao
│ 	├── sustentabilidade
│ 	├── diversidade-inclusao
│ 	├── responsabilidade-social
│ 	└── fale-conosco
│
├── relacoes-com-investidores
│ 	├── visao-geral
│ 	├── comunicados
│ 	├── demonstracoes-financeiras
│ 	├── formularios-de-referencia
│ 	├── rating
│ 	├── governanca-corporativa
│ 	├── diretoria-e-conselho
│ 	├── calendario-de-eventos
│ 	├── documentos-cvm
│ 	├── sustentabilidade-e-esg
│ 	└── contato-ri
│
├── carreiras
│ 	├── trabalhe-conosco
│ 	├── vagas
│ 	├── cultura-evo
│ 	├── beneficios
│ 	├── diversidade
│ 	├── programa-de-estagio
│ 	├── jovens-aprendizes
│ 	├── tecnologia
│ 	├── vendas
│ 	├── atendimento
│ 	├── campo-e-operacoes
│ 	└── banco-de-talentos
│
├── sustentabilidade

-- 20 of 81 --

│ 	├── estrategia-esg
│ 	├── meio-ambiente
│ 	├── eficiencia-energetica
│ 	├── residuos-e-circularidade
│ 	├── impacto-social
│ 	├── inclusao-digital
│ 	├── governanca
│ 	├── relatorios
│ 	└── indicadores
│
├── confianca
│ 	├── seguranca
│ 	│ 	├── canais-oficiais
│ 	│ 	├── como-evitar-golpes
│ 	│ 	├── boletos-oficiais
│ 	│ 	├── whatsapp-oficial
│ 	│ 	├── perfis-oficiais
│ 	│ 	├── denuncia-de-fraude
│ 	│ 	└── seguranca-da-informacao
│ 	├── privacidade
│ 	│ 	├── politica-de-privacidade
│ 	│ 	├── politica-de-cookies
│ 	│ 	├── portal-de-privacidade
│ 	│ 	├── direitos-do-titular
│ 	│ 	├── encarregado-de-dados
│ 	│ 	└── consentimento
│ 	├── compliance
│ 	│ 	├── programa-de-compliance
│ 	│ 	├── codigo-de-conduta
│ 	│ 	├── canal-de-etica
│ 	│ 	├── politicas-corporativas
│ 	│ 	├── fornecedores
│ 	│ 	└── integridade
│ 	└── documentos-legais
│ 	├── termos-de-uso
│ 	├── contratos
│ 	├── regulamentos-de-promocoes
│ 	├── politicas-comerciais
│ 	├── qualidade-e-sla
│ 	├── neutralidade-de-rede
│ 	├── acessibilidade
│ 	└── documentos-regulatorios
│
├── desenvolvedores
│ 	├── documentacao
│ 	├── apis
│ 	├── webhooks

-- 21 of 81 --

│ 	├── status-de-apis
│ 	├── sandbox
│ 	├── integracoes
│ 	└── suporte-tecnico
│
└── mapa-do-site
7. Menu, rodapé e navegação
7.1. Menu principal recomendado
Não colocar toda a árvore no menu principal. O menu deve ser simples, comercial e
compreensível.
Para Você
Para Empresas
Corporate
Governo
Operadoras
Atendimento
Sobre a EVO
CTAs no topo:
Consultar cobertura
Área do cliente
Assine agora
7.2. Rodapé completo
O rodapé deve ser o mapa do ecossistema.
Produtos e Serviços
├── Para Você
├── Para Empresas
├── Corporate
├── Governo
├── Operadoras
Atendimento
├── Central de ajuda
├── Segunda via
├── Área do cliente

-- 22 of 81 --

├── Status da rede
├── Lojas
├── Ouvidoria
Programas
├── Indique
├── Benefícios
├── Parceiros
├── Afiliados
├── Revendas
├── Condomínios
├── Fornecedores
Institucional
├── Sobre a EVO
├── Agora somos EVO
├── Sustentabilidade
├── Carreiras
├── Imprensa
├── Relações com investidores
Confiança
├── Canais oficiais
├── Segurança
├── Privacidade
├── Compliance
├── Canal de ética
├── Documentos legais
Técnico
├── Desenvolvedores
├── Documentação
├── APIs
├── Peering
├── NOC
├── Looking Glass
8. Modelo padrão de páginas
Cada página indexável relevante deve seguir um modelo mínimo.
8.1. Página de produto/solução
Estrutura:

-- 23 of 81 --

1. H1 claro;
2. Subtítulo objetivo;
3. Descrição curta;
4. Benefícios principais;
5. Cards de produtos relacionados;
6. Para quem é;
7. Como funciona;
8. Diferenciais EVO;
9. Disponibilidade/cobertura;
10. Casos de uso;
11. FAQ;
12. CTAs;
13. Links internos;
14. Dados estruturados;
15. Data de atualização.
8.2. Página de programa
Exemplo: /programas/indique
Estrutura:
1. O que é;
2. Como funciona;
3. Quem pode participar;
4. Quem pode ser indicado;
5. Benefício;
6. Regras principais;
7. Regulamento;
8. Perguntas frequentes;

-- 24 of 81 --

9. CTA para sistema;
10. Página de acompanhamento;
11. Links para atendimento.
8.3. Página local/cidade
Estrutura:
1. H1 com cidade e serviço;
2. Cobertura e disponibilidade;
3. Planos/ofertas dinâmicas;
4. Lojas próximas;
5. Serviços disponíveis;
6. FAQ local;
7. Canais oficiais;
8. Links para páginas do estado;
9. Conteúdo específico real, não texto genérico duplicado.
8.4. Página de confiança/segurança
Estrutura:
1. Canais oficiais;
2. Como identificar golpe;
3. WhatsApps oficiais;
4. Perfis oficiais;
5. Boletos oficiais;
6. Pix oficial;
7. Denúncia de fraude;
8. FAQ;
9. Links para privacidade, compliance e atendimento.

-- 25 of 81 --

9. Stack técnica recomendada
9.1. Frontend
Recomendação principal:
Next.js + React + TypeScript
Requisitos:
App Router;
Server Components quando aplicável;
SSR/SSG/ISR conforme tipo de página;
Metadados dinâmicos;
Sitemap dinâmico;
Rotas escaláveis;
Componentização forte;
Testes automatizados;
Integração com CMS headless;
Integração com APIs de oferta;
Suporte a internacionalização futura;
Preparação para páginas locais em escala.
9.2. CMS
Recomendação:
Headless CMS Enterprise
Opções aceitáveis:
Contentful Enterprise;
Storyblok Enterprise;
Sanity Enterprise;
Adobe Experience Manager, apenas se houver decisão corporativa por suíte Adobe.

-- 26 of 81 --

Requisitos mínimos do CMS:
Modelagem estruturada de conteúdo;
Ambientes separados;
Workflow editorial;
Aprovação;
Perfis e permissões;
Histórico de versões;
Preview;
Agendamento de publicação;
Webhooks;
Multi-idioma futuro;
Reutilização de blocos;
Governança de componentes;
API robusta;
Integração com frontend;
Controle de SEO por página;
Campos para schema/structured data;
Auditoria editorial.
9.3. Design system
Stack recomendada:
Figma
Design Tokens
Storybook
React components
Sora como tipografia principal
SVG icons
Motion guidelines
Componentes mínimos:

-- 27 of 81 --

Header;
Mega menu;
Footer;
Hero;
Cards de plano;
Cards de solução;
Cards de setor;
Cards de programa;
Breadcrumb;
FAQ;
Accordion;
Tabs;
CTA;
Formulários;
Tabelas;
Comparadores;
Bloco de cobertura;
Bloco de cidade;
Bloco institucional;
Bloco de confiança;
Bloco de loja;
Bloco de conteúdo;
Bloco de case;
Alertas;
Status;
Landing page builder.

-- 28 of 81 --

9.4. Edge, CDN e segurança de borda
Recomendação:
Cloudflare Enterprise
Escopo mínimo:
DNS;
CDN;
WAF;
DDoS protection;
Bot Management;
Rate Limiting;
API Shield;
mTLS onde aplicável;
Turnstile;
Cache rules;
Image optimization;
Logpush;
Regras por subdomínio;
Zero Trust/Access para ambientes restritos.
9.5. Deploy e hospedagem
Opção recomendada:
Vercel Enterprise para frontend Next.js
Cloudflare Enterprise na borda
Alternativa:
AWS / Azure / GCP / Kubernetes + Cloudflare Enterprise
Requisitos:

-- 29 of 81 --

CI/CD;
Deploy preview;
Ambientes dev/homolog/prod;
Rollback;
Observabilidade;
Gestão de variáveis e secrets;
Build seguro;
Testes automatizados;
SLA;
Logs;
Auditoria;
Separação de permissões.
9.6. APIs e integrações
Arquitetura recomendada:
Frontend
↓
BFF por mercado ou contexto
↓
API Gateway
↓
Offer Hub / CMS / CRM / BSS / OSS / Billing / Atendimento / Data Lake
Requisitos:
Não expor sistemas críticos diretamente ao frontend;
Usar API Gateway;
Autenticação e autorização fortes;
Rate limiting;
Proteção contra scraping;
Validação server-side de preço e oferta;

-- 30 of 81 --

Versionamento de APIs;
OpenAPI specs;
Logs de auditoria;
Observabilidade;
Tratamento de erro padronizado;
Cache estratégico;
Circuit breaker quando aplicável.
9.7. E-commerce externo
Os sistemas transacionais previstos são:
assine.evo.digital
contrate.empresas.evo.digital
A parte dinâmica de catálogo, viabilidade, elegibilidade e contratação poderá rodar nesses
ambientes, mas recomenda-se uma camada canônica de ofertas para não tornar o e-
commerce a única fonte de verdade.
Se os e-commerces forem desenvolvidos em Lovable/React, exigir:
Repositório GitHub sob controle da EVO;
Exportabilidade do código;
CI/CD próprio;
Code review;
Testes automatizados;
SAST/DAST/SCA;
Gestão segura de secrets;
Ambientes separados;
Logs centralizados;
Observabilidade;
Documentação técnica;
Segurança de APIs;

-- 31 of 81 --

Controle de dependências;
Política de backup;
Plano de rollback;
Evitar lock-in sem plano de continuidade.
10. SEO, GEO, IA e presença local
Esta seção foi reescrita para descrever como cada elemento deve ser entregue — não
apenas o que deve existir. Cada bloco traz: boas práticas, entregáveis obrigatórios, o que
não pode faltar e checklist de aceite. As bibliotecas de código (JSON-LD) estão no Anexo
A. O cadastro e a migração das unidades físicas no Google estão no Anexo B. A lista
mestre de checklists por elemento do projeto está no Anexo C.
10.1. SEO técnico
Boas práticas:
URLs limpas, estáveis, em minúsculas, com hífen, sem parâmetros para conteúdo
indexável e sem stop words desnecessárias.
Conteúdo crítico renderizado no servidor (SSR/SSG/ISR). Nada que precise ranquear
pode depender de JavaScript client-side.
Um H1 por página, hierarquia de headings correta, title e meta description únicos por
URL.
Canonical autorreferente em toda página; canonical apontando para a versão correta em
paginação, filtros e variações.
robots.txt enxuto, com referência ao sitemap; noindex aplicado deliberadamente a
checkout, áreas logadas, busca interna e parâmetros.
Sitemap dinâmico, segmentado por tipo (institucional, produtos, cidades, blog) quando o
volume justificar, com lastmod real.
Estratégia de links internos por hub: cada página-mãe aponta para filhas e vice-versa;
páginas de cidade linkam para o estado; produtos linkam para soluções relacionadas.
404 e 410 tratados; 301 planejados e versionados (essencial na migração de marca — ver
§16).
Imagens em formatos modernos (AVIF/WebP), com alt descritivo e dimensões
definidas.

-- 32 of 81 --

Entregáveis obrigatórios:
Mapa de URLs canônicas e plano de redirecionamento (de/para) versionado.
Sitemap(s) e robots.txt em produção.
Search Console e Bing Webmaster Tools configurados, com propriedade de domínio
verificada.
Relatório de cobertura de indexação no go-live e 30 dias depois.
O que não pode faltar:
SSR/SSG para 100% das páginas indexáveis.
Title, description e H1 únicos — zero duplicação.
Plano de 301 fechado antes de qualquer troca de domínio/marca.
Checklist de aceite:
URLs limpas e padronizadas
H1/title/description únicos por página
Canonical correto em todas as páginas
robots.txt + sitemap em produção
noindex aplicado a checkout/logado/busca
Conteúdo crítico em SSR/SSG (validado com JS desativado)
Links internos por hub implementados
404/410/301 testados
Search Console e Bing configurados
10.2. Dados estruturados (JSON-LD / Schema.org)
Padrão único: JSON-LD (não usar microdata/RDFa). Biblioteca completa com código pronto
no Anexo A.
Mapa de schema por tipo de página:
Tipo de
página Schema obrigatório 	Observação
Todas 	BreadcrumbList 	Sempre

-- 33 of 81 --

Home /
global
WebSite (+ SearchAction se
houver busca interna) SearchAction só se a busca existir
Institucional
/ Sobre
Organization (nó canônico) +
ContactPoint + PostalAddress
+ sameAs
Um único nó com @id reutilizável
Produto /
solução Service ou Product + Offer Offer só com preço/condição reais e
vigentes vindos do Offer Hub (§4.5)
Cidade /
loja /
unidade
LocalBusiness (por unidade)
Com geo , openingHours ,
telephone , areaServed , sameAs →
Google Maps
Blog /
notícia Article / NewsArticle Com author , datePublished ,
dateModified
Vagas 	JobPosting 	Datas e localização obrigatórias
Eventos 	Event
Vídeos 	VideoObject
Avaliações 	AggregateRating / Review
Somente se reais, coletadas em
primeira parte e em conformidade.
Nunca inventar
Boas práticas e governança:
Schema é modelado como campos no CMS e gerado no build — não escrito à mão
página por página.
Um único nó Organization canônico com @id fixo (ex.:
https://evo.digital/#organization ), referenciado por @graph nas demais páginas.
Evita duplicação e conflito de entidade.
Preço, oferta e disponibilidade sempre via Offer Hub (§4.5). Preço nunca é digitado no
CMS nem fixado no código.
Toda marcação deve corresponder ao conteúdo visível na página. Schema que descreve
algo que não está na página é passivo (risco de ação manual e de ser ignorado por IA).
Validação automática em CI (validador de schema) e checagem pontual no Rich Results
Test.
Dono e versão por tipo de schema (entra na governança editorial, §22).

-- 34 of 81 --

O que não pode faltar:
@id consistente para entidades reutilizadas (Organization, LocalBusiness).
Organization.sameAs com todos os perfis oficiais (redes sociais, RA, Maps) — ver §10.5.
Paridade entre schema e conteúdo visível.
Checklist de aceite:
JSON-LD em todas as páginas relevantes (ver tabela)
Nó Organization único com @id canônico
BreadcrumbList em 100% das páginas
Offer alimentado pelo Offer Hub, nunca hardcoded
LocalBusiness por unidade com geo + sameAs → Maps
Validação de schema no CI sem erro crítico
Schema == conteúdo visível (auditado por amostragem)
Review / AggregateRating apenas reais e em conformidade
10.3. FAQs
Contexto atual (obrigatório entender): desde 7 de maio de 2026 o Google deixou de
exibir o rich result de FAQ no resultado de busca, para todos os tipos de site. O relatório de
FAQ no Search Console e o suporte no Rich Results Test são removidos em junho/2026; a
API do Search Console deixa de retornar esse dado em agosto/2026. O tipo FAQPage do
Schema.org continua válido, e conteúdo em perguntas e respostas segue sendo um dos
formatos mais citados por mecanismos generativos (AI Overviews, Gemini, ChatGPT,
Perplexity, Copilot).
Conclusão prática para a EVO: FAQ deixou de ser alavanca de rich snippet no Google.
Passa a ser ativo de GEO/IA e de clareza semântica. A FAQ não some — muda de função.
Boas práticas:
Manter blocos de FAQ reais e visíveis onde há dúvida legítima: produto, programa,
cidade, confiança, migração de marca.
Marcar com FAQPage (JSON-LD) somente quando o Q&A está visível na página e o texto
da marcação é idêntico ao texto visível.
Usar QAPage apenas em páginas de comunidade/suporte com múltiplas respostas de
usuários. Nunca confundir com FAQPage .

-- 35 of 81 --

Respostas otimizadas para citação por IA: começam pela resposta, são autossuficientes,
têm ~80 a ~150 palavras e evitam “depende”.
Não inflar FAQ artificialmente só para marcar schema. Conteúdo fraco com schema vira
passivo.
Perguntas baseadas em busca real: Search Console, “As pessoas também perguntam”,
Q&A do Google Business Profile, atendimento e reclamações (RA).
Para o local (loja/unidade), a superfície de FAQ que sobreviveu é o Q&A do Google
Business Profile: semear as perguntas reais, responder como proprietário (owner-
verified) e auditar respostas de terceiros (ver Anexo B).
Entregáveis obrigatórios:
Biblioteca de 8–15 perguntas por template de produto, 6–10 por página de cidade, 10+
para migração de marca e canais oficiais.
Componente de FAQ acessível (accordion navegável por teclado, ARIA correto).
Geração do FAQPage a partir do conteúdo do CMS, campo a campo, com validação.
O que não pode faltar:
Paridade exata entre texto visível e JSON-LD.
Resposta-primeiro em cada item.
Q&A do GBP semeado e respondido nas unidades.
Checklist de aceite:
FAQ visível e útil (não decorativa)
FAQPage apenas onde há Q&A visível
Texto do schema idêntico ao texto da página
Respostas com 80–150 palavras, diretas
QAPage não usado no lugar de FAQPage
Q&A do GBP semeado e respondido (unidades)
Nenhuma FAQ inflada só para schema
10.4. Google Business Profile e cadastro das unidades EVO
Hoje, avaliações, fotos, fichas e histórico de ranqueamento local vivem sob as marcas
legadas (Amigo, Ávato, Blink, JustWeb, Sempre, GGNET/ALT, OnNet). Esse é um dos ativos

-- 36 of 81 --

digitais mais valiosos da companhia e não pode ser perdido na transição para EVO.
Playbook completo no Anexo B.
Princípio inegociável: a regra oficial do Google permite rebrand com múltiplas
localizações preservando as avaliações, desde que feito como mudança de nome no perfil
existente. Apagar e recriar perfil zera avaliações, fotos e histórico. Portanto: renomear,
nunca recriar.
Boas práticas (resumo):
Inventário completo de todos os perfis, donos, e-mails de acesso e status de verificação
antes de tocar em qualquer coisa.
Padronizar NAP (Nome, Endereço, Telefone), naming EVO, categorias e atributos.
Sequência segura: atualizar site e NAP primeiro → renomear o perfil → demais campos
depois. Não mudar nome, endereço, telefone e categoria de uma vez.
Operar em escala via grupo de localizações e API do Google Business Profile (upload
em massa), não unidade por unidade no painel.
Verificação por vídeo é comum em 2026: preparar sinalização física com a marca EVO,
materiais, veículos e documentos.
Vincular a página oficial da unidade no site ( evo.digital/lojas/[estado]/[cidade] ), as
redes sociais e publicar post de rebrand.
301 nos sites das marcas antigas antes de trocar as URLs no GBP.
Em rebrand de grande porte, acionar o suporte do GBP / gerente de conta Google
previamente.
Política de avaliações 2026 (o que é proibido): não incentivar avaliações (pagamento,
desconto, brinde), não usar quiosque/tablet compartilhado no balcão, não fazer gating (pré-
filtrar quem avalia) e não pedir que o cliente cite o nome de funcionários. Violações estão
sendo removidas por enforcement automatizado.
O que não pode faltar:
Nenhum perfil apagado/recriado.
NAP idêntico entre GBP, site, redes e diretórios.
Verificação concluída em todas as unidades ativas.
Checklist de aceite: ver Anexo B (checklist por unidade).
10.5. Redes sociais, perfis oficiais e NAP

-- 37 of 81 --

Boas práticas:
Definir handles oficiais únicos e padronizados em todos os canais (placeholders:
@evodigital / evo.digital ), antes do lançamento.
On-site: Organization.sameAs (JSON-LD) lista todos os perfis oficiais; links no rodapé;
rel="me" onde aplicável.
Página /confianca/canais-oficiais (e /perfis-oficiais ) como fonte da verdade de
canais — serve ao antifraude (§11.3) e ao GEO (a IA usa essa página para validar a
marca).
NAP idêntico em site, GBP, redes sociais, diretórios, RA e mapas. Qualquer divergência
derruba confiança local e prejudica citação por IA.
Vincular os perfis sociais no próprio Google Business Profile (campo de redes sociais
hoje suportado).
Consolidar diretórios/citações e manter o selo de reputação (ex.: RA1000) coerente com
a marca EVO.
Migração: as redes das marcas antigas devem comunicar a transição, atualizar bios e
apontar para evo.digital .
Entregáveis obrigatórios:
Matriz de handles oficiais por rede (atual marca → EVO).
Padrão NAP único documentado.
Organization.sameAs implementado e página de canais oficiais publicada.
O que não pode faltar:
NAP 100% consistente.
Página de canais oficiais indexável e linkada no rodapé.
sameAs cobrindo todos os perfis reais (e nenhum perfil falso/abandonado).
Checklist de aceite:
Handles oficiais definidos e padronizados
Organization.sameAs com todos os perfis
Página de canais oficiais publicada e linkada
NAP idêntico em site/GBP/redes/diretórios

-- 38 of 81 --

Redes sociais vinculadas no GBP
Bios das marcas antigas atualizadas para EVO
10.6. GEO / AEO / IA (mecanismos generativos)
As páginas devem ser estruturadas para serem compreendidas e citadas por mecanismos
generativos. Não há schema secreto que garanta citação: o que pesa é conteúdo claro,
factual e verificável, com entidade bem definida.
Princípio dos dois níveis (padrão EVO): toda afirmação relevante deve ter (1) uma fonte de
terceiros verificável e (2) conteúdo on-site ancorado a ela. A IA cita quem é claro,
consistente e corroborável.
Boas práticas:
Resposta direta no início de cada página/seção.
Conteúdo factual, com dados verificáveis, tabelas simples e definições claras.
Entidade canônica consistente ( Organization com @id , sameAs , NAP) e @graph
coerente entre páginas.
Data de atualização e autoria institucional visíveis.
Páginas-resposta oficiais de marca e de canais oficiais (lista abaixo).
Baixa ambiguidade e ausência de jargão interno.
Conteúdo local real (não duplicado em massa).
Páginas-resposta obrigatórias:
/evo-e-a-nova-marca-da-amigo
/evo-e-a-nova-marca-da-avato
/evo-e-a-nova-marca-da-blink
/evo-e-a-nova-marca-da-ligga
/brasil-tecpar-agora-evo
/canais-oficiais
/segunda-via-evo
/telefone-evo
/whatsapp-evo
/app-evo
/lojas-evo
/consultar-cobertura-evo
/evo-empresas
/evo-corporate
/evo-governo

-- 39 of 81 --

/evo-wholesale
O que não pode faltar:
Resposta-primeiro e dados verificáveis nas páginas-resposta.
Entidade e sameAs consistentes em todo o site.
Páginas-resposta de marca publicadas no lançamento.
Checklist de aceite:
Páginas-resposta de marca publicadas
Resposta-primeiro nas páginas-chave
Entidade canônica + sameAs consistentes
Data de atualização e autoria visíveis
Conteúdo local real (sem duplicação em massa)
10.7. SEO local em escala
Criar páginas reais por cidade/estado conforme a cobertura, com conteúdo próprio e útil.
Não gerar páginas finas e duplicadas em massa — Google penaliza e a IA ignora.
Padrão de URL:
/internet/[estado]/[cidade]
/lojas/[estado]/[cidade]
/cobertura/[estado]/[cidade]
/empresas/internet/[estado]/[cidade]
/cidades/[estado]/[cidade]
Boas práticas:
Cada página local com conteúdo específico real: cobertura, planos dinâmicos (via Offer
Hub), unidades próximas, serviços disponíveis, FAQ local e canais oficiais.
LocalBusiness por unidade (Anexo A) com sameAs apontando para o perfil no Google
Maps.
Links internos da cidade para o estado e para produtos relacionados.
Geração programática governada: template + dados reais por localidade, com bloqueio
de publicação quando o conteúdo mínimo não existe.
Alinhamento total com o cadastro do Google Business Profile (Anexo B): a página local é

-- 40 of 81 --

o destino oficial vinculado ao perfil.
O que não pode faltar:
Conteúdo único por cidade (nada de texto-modelo trocando só o nome).
LocalBusiness + vínculo com GBP.
Bloqueio de publicação para páginas sem conteúdo mínimo.
Checklist de aceite:
Padrão de URL local implementado
Conteúdo único e útil por cidade
LocalBusiness por unidade com sameAs → Maps
Planos dinâmicos via Offer Hub na página local
FAQ local + canais oficiais presentes
Links internos cidade→estado→produto
Trava contra páginas finas/duplicadas
10.8. Critérios de aceite consolidados de SEO/GEO
100% das páginas indexáveis em SSR/SSG
Metadados únicos e canonical correto em toda página
Sitemap + robots + Search Console + Bing ativos
JSON-LD validado no CI, sem erro crítico
Organization canônico + sameAs completos
Páginas-resposta de marca publicadas
Páginas locais com conteúdo único + LocalBusiness
FAQ tratada como ativo de GEO (não de rich result)
Plano de 301 da migração de marca fechado e testado
Google Business Profile inventariado e plano de rebrand aprovado (Anexo B)
11. Segurança e privacidade

-- 41 of 81 --

11.1. Requisitos mínimos de segurança
WAF;
DDoS protection;
Bot Management;
API Shield;
Rate limiting;
CSP;
HSTS;
Security headers;
TLS moderno;
Proteção contra XSS, CSRF, SSRF, injection;
OWASP ASVS como baseline;
OWASP API Security Top 10;
SAST;
DAST;
SCA;
Secret scanning;
IaC scanning;
Pentest antes do go-live;
Logs de auditoria;
Monitoramento de anomalias;
Backups;
Plano de incidentes;
Gestão de vulnerabilidades;
Separação de ambientes;
SSO/MFA para administradores;
RBAC no CMS;

-- 42 of 81 --

Aprovação editorial;
Proteção de ambientes dev/homolog com Zero Trust.
11.2. LGPD e consentimento
Requisitos:
CMP/gestão de cookies;
Política de privacidade;
Política de cookies;
Portal de direitos do titular;
Registro de consentimento;
Minimização de dados;
Finalidade por formulário;
Retenção definida;
Data mapping;
Integração com DPO/encarregado;
Logs de consentimento;
Privacy by design;
Privacy by default.
11.3. Antifraude e proteção de marca
Páginas obrigatórias:
Canais oficiais;
Como evitar golpes;
Boletos oficiais;
Pix oficial;
WhatsApp oficial;
Perfis oficiais;
Denúncia de fraude;

-- 43 of 81 --

Segurança da informação;
Validar comunicação recebida.
12. Acessibilidade
Meta mínima:
WCAG 2.2 AA
Requisitos:
Contraste adequado;
Navegação por teclado;
Semântica HTML correta;
Landmarks;
Labels;
Alt text;
Foco visível;
Formulários acessíveis;
Mensagens de erro acessíveis;
ARIA somente quando necessário;
Testes com ferramentas automatizadas;
Testes manuais;
Documentação de acessibilidade;
Página de atendimento acessível.
13. Performance
Metas mínimas:
LCP < 2,5s

-- 44 of 81 --

INP < 200ms
CLS < 0,1
Requisitos:
Performance budget por template;
Imagens responsivas;
Fontes otimizadas e self-hosted quando aplicável;
Scripts de terceiros controlados;
Lazy loading;
Code splitting;
Cache na borda;
Pré-renderização;
CDN;
Monitoramento RUM;
Lighthouse CI;
Relatórios periódicos;
Não usar animações pesadas sem necessidade;
Evitar carrosséis inúteis;
Evitar dependência excessiva de JavaScript client-side para conteúdo crítico.
14. Analytics, dados e mensuração
14.1. Stack recomendada
GA4;
Google Tag Manager Server-Side;
BigQuery;
Looker Studio ou Power BI;
Microsoft Clarity / Hotjar / Contentsquare;

-- 45 of 81 --

Segment ou RudderStack, se aplicável;
Consent Management Platform;
Integração com Salesforce/CRM;
Dashboards executivos.
14.2. Eventos mínimos
page_view
view_market
view_product
view_solution
view_offer
check_coverage_start
check_coverage_success
check_coverage_fail
plan_selected
cta_click
lead_submit
request_quote
start_checkout
finish_checkout
click_whatsapp
click_call
download_material
view_city_page
view_b2b_solution
view_program
partner_form_submit
supplier_form_submit
referral_start
referral_submit
14.3. Parâmetros mínimos
session_id
handoff_id
utm_source
utm_medium
utm_campaign
utm_content
utm_term
market
product_category

-- 46 of 81 --

solution_category
city
state
cep_hash
customer_type
page_type
cta_type
campaign_id
ab_test_variant
15. Conteúdo editorial
15.1. Tom de voz
Claro;
Próximo;
Confiável;
Humano;
Técnico quando necessário;
Sem excesso de jargão;
Sem linguagem infantil;
Sem promessas vazias;
Sem “líder em soluções inovadoras” como muleta;
Com foco em benefício real.
15.2. Hubs de conteúdo
Criar hubs para:
Internet;
Móvel;
Casa conectada;
Pequenas e médias empresas;
Corporate;

-- 47 of 81 --

Governo;
Operadoras;
Cloud;
Cyber;
IoT;
Setores;
Segurança;
Ajuda;
Migração de marca;
Sustentabilidade;
Carreiras.
15.3. Conteúdo mínimo para lançamento
A contratada deverá propor a quantidade mínima de páginas para lançamento, mas
recomenda-se:
Home;
5 páginas de mercados;
30+ páginas de produtos/soluções;
10 páginas de setores;
10 páginas institucionais;
15 páginas de atendimento/confiança;
10 páginas de programas;
páginas de migração de marca;
páginas locais prioritárias;
blog/newsroom inicial;
central de ajuda inicial.

-- 48 of 81 --

16. Migração de marcas
Criar estratégia de migração digital para marcas atuais e adquiridas.
16.1. Páginas obrigatórias
/agora-somos-evo
/brasil-tecpar-agora-evo
/amigo-agora-evo
/avato-agora-evo
/blink-agora-evo
/ligga-agora-evo
/o-que-muda-para-o-cliente
/o-que-nao-muda-para-o-cliente
/canais-oficiais-da-evo
16.2. Mensagem padrão
A [marca atual] agora é EVO. Seu plano continua o mesmo. O atendimento continua
próximo. E agora você passa a contar com uma marca nacional, com mais tecnologia,
cobertura e soluções digitais.
16.3. Requisitos de migração SEO
Inventário de URLs antigas;
Redirecionamentos 301;
Preservação de autoridade;
Atualização de Search Console;
Atualização de Google Business Profile;
Monitoramento de queda de tráfego;
Plano de comunicação para clientes;
Páginas explicativas para marcas legadas;
Atualização de canais oficiais.
17. Integrações previstas
A contratada deverá mapear e documentar integrações com:

-- 49 of 81 --

CMS;
Offer Hub;
API Gateway;
CRM/Salesforce;
SAP;
BSS/OSS;
Billing;
E-commerce assine.evo.digital ;
Portal contrate.empresas.evo.digital ;
Área do cliente;
Zendesk/atendimento;
WhatsApp;
Google Business Profile;
Plataformas de analytics;
Data lake;
App;
Status page;
Portais de parceiros;
Portal de fornecedores;
Sistemas de RI;
Carreiras/vagas;
Plataforma de consentimento;
Ferramentas de segurança.
18. Entregáveis obrigatórios da contratada
18.1. Estratégia e arquitetura

-- 50 of 81 --

Diagnóstico inicial;
Arquitetura de informação;
Sitemap completo;
Estratégia de SEO/GEO;
Estratégia de conteúdo;
Estratégia de migração;
Jornada dos usuários;
Arquitetura de subdomínios;
Plano de redirecionamento;
Plano de governança.
18.2. UX/UI
Wireframes;
Protótipos navegáveis;
Design system;
Componentes;
Templates;
Versões desktop/tablet/mobile;
Acessibilidade;
Documentação de uso.
18.3. Tecnologia
Frontend;
Integração CMS;
Integração APIs;
Infraestrutura;
CI/CD;
Ambientes;

-- 51 of 81 --

Segurança;
Observabilidade;
Testes;
Documentação técnica.
18.4. Conteúdo
Modelos de conteúdo;
Redação SEO;
Páginas institucionais;
Páginas comerciais;
Páginas de programas;
Páginas de confiança;
Páginas de migração;
Metadados;
FAQs;
Structured data;
Guidelines editoriais.
18.5. Go-live
Plano de lançamento;
Checklist técnico;
Checklist SEO;
Checklist de segurança;
Checklist LGPD;
Checklist de acessibilidade;
Monitoramento pós-go-live;
Plano de rollback;
Treinamento.

-- 52 of 81 --

19. Critérios de aceite
19.1. Técnico
Build sem erros;
Testes passando;
Lighthouse dentro das metas;
Core Web Vitals dentro das metas;
Sem erros críticos de SEO;
Structured data válido;
Sitemap funcional;
Robots correto;
Segurança validada;
CMS funcional;
Preview funcional;
Integrações testadas;
Logs e monitoramento ativos.
19.2. Conteúdo
Páginas completas;
Sem lorem ipsum;
Metadados únicos;
H1 correto;
CTAs corretos;
Links internos;
FAQ quando aplicável;
Conteúdo revisado;
Sem duplicação indevida;

-- 53 of 81 --

Aprovação de jurídico/compliance quando necessário.
19.3. SEO/GEO
Search Console configurado;
Sitemaps enviados;
Redirects validados;
Structured data sem erro crítico;
Páginas prioritárias indexáveis;
Canonicals corretos;
Páginas noindex onde necessário;
Performance validada.
19.4. Segurança
Pentest realizado;
Vulnerabilidades críticas corrigidas;
WAF ativo;
Headers ativos;
SSO/MFA em áreas administrativas;
CMS com RBAC;
Ambientes restritos protegidos;
Logs ativos;
Plano de resposta a incidentes.
20. O que fazer
A contratada deve:
1. Projetar para escala nacional;
2. Priorizar SEO, GEO e conteúdo estruturado;
3. Criar design system real;

-- 54 of 81 --

4. Separar conteúdo de transação;
5. Proteger autoridade do domínio principal;
6. Criar páginas públicas para todo o ecossistema;
7. Usar subdomínios para sistemas;
8. Pensar em mobile first;
9. Garantir performance;
10. Garantir acessibilidade;
11. Implementar segurança desde o início;
12. Documentar tudo;
13. Treinar o time;
14. Criar governança editorial;
15. Planejar migração de marcas;
16. Planejar expansão de páginas locais;
17. Garantir autonomia do marketing sem quebrar o site;
18. Garantir integração com APIs e sistemas corporativos;
19. Criar componentes reutilizáveis;
20. Evitar dependência excessiva de fornecedor.
21. O que não fazer
A contratada não deve:
1. Entregar apenas um site institucional simples;
2. Criar um WordPress monolítico sem justificativa robusta;
3. Misturar checkout com conteúdo SEO;
4. Colocar preço e elegibilidade manualmente no CMS;
5. Criar subdomínio para cada produto sem necessidade;
6. Criar hotsites soltos sem governança;

-- 55 of 81 --

7. Criar páginas dependentes de JavaScript client-side para conteúdo crítico;
8. Usar templates genéricos sem design system;
9. Ignorar SEO local;
10. Ignorar migração das marcas legadas;
11. Ignorar segurança, LGPD e antifraude;
12. Criar navegação com siglas internas;
13. Criar conteúdo genérico ou duplicado em massa;
14. Usar ícones e grafismos sem padrão;
15. Entregar sem documentação;
16. Entregar sem testes;
17. Entregar sem observabilidade;
18. Entregar sem plano de rollback;
19. Entregar sem treinamento;
20. Entregar algo que só o fornecedor consegue manter.
22. Governança recomendada
Criar comitês ou ritos:
Fórum 	Função
Brand Council 	Marca, visual, tom, campanhas
Digital Council 	Portal, UX, analytics, SEO, tecnologia
Product Council 	Produtos, ofertas, catálogo, bundles
Content Council 	Conteúdo, editorial, páginas, atualização
Security & Trust Council 	Segurança, fraude, LGPD, canais oficiais
Migration Office 	Migração de marcas e URLs
Performance Review 	Core Web Vitals, SEO e conversão

-- 56 of 81 --

Cada página crítica deve ter:
Dono de negócio
Dono editorial
Dono técnico
Frequência de revisão
Status de publicação
Data de atualização
Indicadores
23. Roadmap sugerido
Onda 0 — Preparação
Inventário de marcas, domínios e canais;
Validação de stack;
Validação CMS;
Arquitetura técnica;
Arquitetura de informação;
Priorização de páginas;
Setup de design system;
Setup de ambientes.
Onda 1 — Lançamento mínimo robusto
Home;
Mercados principais;
Produtos prioritários;
Programas principais;
Atendimento;
Confiança;
Sobre;
Migração de marca;

-- 57 of 81 --

Integração com assine e contrate ;
SEO técnico;
Analytics;
Segurança.
Onda 2 — Escala comercial
Páginas locais;
Páginas de setores;
Conteúdo editorial;
Central de ajuda ampliada;
Portais de parceiros;
Fornecedores;
Indique;
Benefícios;
Campanhas;
Otimização de conversão.
Onda 3 — Ecossistema avançado
Wholesale técnico;
Docs/API;
Looking Glass;
Trust Center;
Conteúdo GEO avançado;
IA/busca inteligente;
Personalização;
Testes A/B;
Dashboards executivos.

-- 58 of 81 --

24. Critérios de avaliação da RFP
24.1. Peso sugerido
Critério 	Peso
Entendimento estratégico 	15%
Arquitetura de informação e SEO/GEO 	15%
Capacidade técnica 	15%
UX/UI e design system 	15%
Segurança, LGPD e performance 	10%
Experiência em projetos enterprise 	10%
Conteúdo e governança editorial 	10%
Metodologia e cronograma 	5%
Custo total e modelo de sustentação 	5%
24.2. Perguntas obrigatórias ao fornecedor
1. Qual stack propõe e por quê?
2. Como garantirá SEO técnico e GEO?
3. Como modelará o CMS?
4. Como integrará APIs de oferta e e-commerce externo?
5. Como tratará páginas locais em escala?
6. Como garantirá Core Web Vitals?
7. Como tratará segurança e OWASP?
8. Como garantirá WCAG 2.2 AA?
9. Como será o design system?
10. Como será a governança editorial?
11. Como será a migração das marcas legadas?

-- 59 of 81 --

12. Como será a documentação?
13. Como evitará lock-in?
14. Como será a sustentação pós-go-live?
15. Quais cases comparáveis possui?
25. Referências técnicas e normativas
As propostas devem considerar, no mínimo, as seguintes referências públicas e boas
práticas:
Google Search Central — JavaScript SEO Basics:
https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-
basics
Google Search Central — Structured Data:
https://developers.google.com/search/docs/appearance/structured-data/intro-
structured-data
Google Search Central — Sitemaps: https://developers.google.com/search/docs/crawling-
indexing/sitemaps/overview
Google Search Central — Core Web Vitals:
https://developers.google.com/search/docs/appearance/core-web-vitals
Web.dev — Core Web Vitals thresholds: https://web.dev/articles/defining-core-web-
vitals-thresholds
Next.js — Sitemap metadata file: https://nextjs.org/docs/app/api-reference/file-
conventions/metadata/sitemap
Next.js — Metadata API: https://nextjs.org/docs/app/getting-started/metadata-and-og-
images
Cloudflare — API Shield: https://www.cloudflare.com/products/api-shield/
Cloudflare — Web Security Platform: https://www.cloudflare.com/solutions/security/
OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/
OWASP API Security Top 10: https://owasp.org/API-Security/
W3C WCAG 2.2: https://www.w3.org/TR/WCAG22/
W3C Understanding WCAG 2.2: https://www.w3.org/WAI/WCAG22/Understanding/

-- 60 of 81 --

Google Tag Manager Server-Side: https://developers.google.com/tag-platform/tag-
manager/server-side
26. Conclusão
A EVO não deve contratar apenas um fornecedor de site. Deve contratar um parceiro capaz
de desenhar e executar uma plataforma digital pública de marca, aquisição, relacionamento,
conteúdo, confiança, programas, atendimento e escala.
O entregável esperado precisa ser compatível com uma empresa nacional de tecnologia e
conectividade, com milhões de clientes, presença física, operação digital, mercado
corporativo, governo, wholesale internacional, programas de parceiros, canais de
atendimento e expansão acelerada.
A entrega deve permitir que a EVO nasça com:
Marca forte;
Portal robusto;
Conteúdo profundo;
SEO e GEO preparados;
Segurança real;
Design system escalável;
Integração com e-commerce e portais;
Governança editorial;
Base técnica moderna;
Capacidade de evolução contínua.
A régua não é “um site bonito”.
A régua é:
um ecossistema digital que suporte uma companhia nacional rumo a 5 milhões de
acessos, sem virar um puxadinho digital com DNS elegante.
Anexo A — Biblioteca de dados estruturados (JSON-LD)

-- 61 of 81 --

Código pronto para implementação. Todos os exemplos usam evo.digital como domínio
canônico e a ASN da operação ( AS53062 ). Campos entre colchetes ou com 0000 são
placeholders a serem preenchidos pelo CMS/Offer Hub. Regra de ouro: o JSON-LD deve
refletir o conteúdo visível na página.
A.1. Organization (nó canônico — uma vez, reutilizado por @id )
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://evo.digital/#organization",
"name": "EVO",
"legalName": "Brasil Tecnologia e Participações S/A",
"url": "https://evo.digital",
"logo": {
"@type": "ImageObject",
"url": "https://evo.digital/brand/evo-logo.png",
"width": 512,
"height": 512
},
"slogan": "Conectando o que Vem Depois",
"foundingDate": "[ANO]",
"taxID": "[CNPJ]",
"areaServed": "BR",
"contactPoint": [
{
"@type": "ContactPoint",
"telephone": "+55-0800-000-0000",
"contactType": "customer service",
"areaServed": "BR",
"availableLanguage": ["Portuguese"]
},
{
"@type": "ContactPoint",
"telephone": "+55-0800-000-0001",
"contactType": "sales",
"areaServed": "BR",
"availableLanguage": ["Portuguese"]
}
],
"sameAs": [
"https://www.instagram.com/evodigital",
"https://www.facebook.com/evodigital",
"https://www.linkedin.com/company/evodigital",
"https://www.youtube.com/@evodigital",
"https://x.com/evodigital",

-- 62 of 81 --

"https://www.tiktok.com/@evodigital",
"https://www.reclameaqui.com.br/empresa/evo"
]
}
A.2. WebSite (+ SearchAction, somente se houver busca interna)
{
"@context": "https://schema.org",
"@type": "WebSite",
"@id": "https://evo.digital/#website",
"url": "https://evo.digital",
"name": "EVO",
"publisher": { "@id": "https://evo.digital/#organization" },
"inLanguage": "pt-BR",
"potentialAction": {
"@type": "SearchAction",
"target": {
"@type": "EntryPoint",
"urlTemplate": "https://evo.digital/busca?q={search_term_string}"
},
"query-input": "required name=search_term_string"
}
}
A.3. LocalBusiness (uma por unidade EVO)
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"@id": "https://evo.digital/lojas/sp/barueri/unidade-alphaville#localbusiness",
"name": "EVO — Barueri (Alphaville)",
"parentOrganization": { "@id": "https://evo.digital/#organization" },
"url": "https://evo.digital/lojas/sp/barueri/unidade-alphaville",
"image": "https://evo.digital/lojas/sp/barueri/unidade-alphaville/foto.jpg",
"telephone": "+55-11-0000-0000",
"priceRange": "$$",
"address": {
"@type": "PostalAddress",
"streetAddress": "[Rua, número]",
"addressLocality": "Barueri",
"addressRegion": "SP",
"postalCode": "00000-000",
"addressCountry": "BR"
},

-- 63 of 81 --

sameAs deve apontar para a ficha desta unidade no Google Maps. Esse vínculo conecta a
página do site ao Google Business Profile (Anexo B) e reforça a entidade local.
A.4. Service (página de produto/solução)
{
"@context": "https://schema.org",
"@type": "Service",
"name": "Internet Fibra EVO",
"serviceType": "Internet banda larga via fibra óptica",
"provider": { "@id": "https://evo.digital/#organization" },
"areaServed": { "@type": "Country", "name": "Brasil" },
"url": "https://evo.digital/para-voce/internet/internet-fibra",
"description": "[Descrição visível na página, sem promessa vazia]"
}
A.5. Product + Offer (somente com oferta real e vigente, vinda do Offer Hub)
{
"@context": "https://schema.org",
"geo": {
"@type": "GeoCoordinates",
"latitude": "-00.000000",
"longitude": "-00.000000"
},
"areaServed": { "@type": "City", "name": "Barueri" },
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "09:00",
"closes": "18:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Saturday"],
"opens": "09:00",
"closes": "13:00"
}
],
"sameAs": [
"https://www.google.com/maps/place/?q=place_id:[PLACE_ID_DA_UNIDADE]"
]
}

-- 64 of 81 --

"@type": "Product",
"name": "Plano EVO Fibra 700 Mega",
"brand": { "@id": "https://evo.digital/#organization" },
"url": "https://evo.digital/para-voce/internet/planos-de-internet/fibra-700",
"offers": {
"@type": "Offer",
"priceCurrency": "BRL",
"price": "[PRECO_DO_OFFER_HUB]",
"priceValidUntil": "[YYYY-MM-DD]",
"availability": "https://schema.org/InStock",
"areaServed": "BR",
"url": "https://assine.evo.digital/fibra-700",
"seller": { "@id": "https://evo.digital/#organization" }
}
}
price , priceValidUntil e availability sempre vêm do Offer Hub (§4.5). Nunca
digitados no CMS nem fixados no código.
A.6. BreadcrumbList (em todas as páginas)
A.7. FAQPage (uso pós-maio/2026)
Ver §10.3. O rich result foi descontinuado; mantenha o FAQPage apenas onde houver Q&A
visível, para clareza semântica e citação por IA. Texto do schema idêntico ao da página.
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Início", "item": "https://evo.digital" },
{ "@type": "ListItem", "position": 2, "name": "Para Você", "item": "https://evo.digital/pa
{ "@type": "ListItem", "position": 3, "name": "Internet", "item": "https://evo.digital/par
{ "@type": "ListItem", "position": 4, "name": "Internet Fibra", "item": "https://evo.digit
]
}
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "A EVO tem cobertura na minha cidade?",
"acceptedAnswer": {

-- 65 of 81 --

A.8. Article / NewsArticle (blog e newsroom)
{
"@context": "https://schema.org",
"@type": "NewsArticle",
"headline": "[Título da matéria]",
"image": ["https://evo.digital/novidades/[slug]/capa.jpg"],
"datePublished": "[YYYY-MM-DDThh:mm:ss-03:00]",
"dateModified": "[YYYY-MM-DDThh:mm:ss-03:00]",
"author": { "@type": "Organization", "name": "EVO" },
"publisher": { "@id": "https://evo.digital/#organization" },
"mainEntityOfPage": "https://evo.digital/novidades/[slug]"
}
A.9. JobPosting (carreiras)
{
"@context": "https://schema.org",
"@type": "JobPosting",
"title": "[Cargo]",
"datePosted": "[YYYY-MM-DD]",
"validThrough": "[YYYY-MM-DD]",
"employmentType": "FULL_TIME",
"hiringOrganization": { "@id": "https://evo.digital/#organization" },
"jobLocation": {
"@type": "Place",
"address": {
"@type": "PostalAddress",
"addressLocality": "[Cidade]",
"addressRegion": "[UF]",
"@type": "Answer",
"text": "[Resposta direta, 80–150 palavras, idêntica ao texto visível na página.]"
}
},
{
"@type": "Question",
"name": "Como faço a segunda via do boleto EVO?",
"acceptedAnswer": {
"@type": "Answer",
"text": "[Resposta direta, idêntica ao texto visível na página.]"
}
}
]
}

-- 66 of 81 --

"addressCountry": "BR"
}
},
"url": "https://carreiras.evo.digital/vagas/[slug]"
}
A.10. @graph unificado para página de cidade/unidade
Padrão recomendado para páginas locais: um único bloco @graph reunindo as entidades,
com referência ao Organization canônico por @id (sem reescrevê-lo).
{
"@context": "https://schema.org",
"@graph": [
{ "@type": "Organization", "@id": "https://evo.digital/#organization" },
{
"@type": "LocalBusiness",
"@id": "https://evo.digital/lojas/sp/barueri/unidade-alphaville#localbusiness",
"name": "EVO — Barueri (Alphaville)",
"parentOrganization": { "@id": "https://evo.digital/#organization" },
"url": "https://evo.digital/lojas/sp/barueri/unidade-alphaville",
"telephone": "+55-11-0000-0000",
"address": {
"@type": "PostalAddress",
"addressLocality": "Barueri",
"addressRegion": "SP",
"addressCountry": "BR"
},
"geo": { "@type": "GeoCoordinates", "latitude": "-00.000000", "longitude": "-00.000000"
"sameAs": ["https://www.google.com/maps/place/?q=place_id:[PLACE_ID]"]
},
{
"@type": "Service",
"name": "Internet Fibra EVO em Barueri",
"provider": { "@id": "https://evo.digital/#organization" },
"areaServed": { "@type": "City", "name": "Barueri" }
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Início", "item": "https://evo.digital"
{ "@type": "ListItem", "position": 2, "name": "Lojas", "item": "https://evo.digital/lo
{ "@type": "ListItem", "position": 3, "name": "São Paulo", "item": "https://evo.digita
{ "@type": "ListItem", "position": 4, "name": "Barueri", "item": "https://evo.digital/
]
},

-- 67 of 81 --

A.11. Injeção em Next.js (App Router)
Renderizar o JSON-LD no servidor, como <script type="application/ld+json"> ,
dentro do componente da página (Server Component) ou via Metadata, garantindo que
apareça no HTML inicial (não injetar via client-side).
Montar o objeto a partir dos dados do CMS/Offer Hub e serializar com JSON.stringify .
Centralizar a montagem em helpers versionados ( lib/schema/organization.ts ,
lib/schema/localbusiness.ts , etc.), com testes.
A.12. Checklist de validação de schema
JSON-LD presente no HTML inicial (server-side), não via client
Organization único com @id canônico, referenciado por @id nas demais páginas
BreadcrumbList em 100% das páginas
{
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "A EVO tem fibra em Barueri?",
"acceptedAnswer": { "@type": "Answer", "text": "[Resposta idêntica ao texto visível.
}
]
}
]
}
// Exemplo simplificado (Server Component)
export default function Page({ data }) {
const jsonLd = buildLocalBusinessGraph(data); // monta a partir do CMS/Offer Hub
return (
<>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
/>
{/* conteúdo visível correspondente ao schema */}
</>
);
}

-- 68 of 81 --

LocalBusiness por unidade com geo + sameAs → Maps
Offer alimentado pelo Offer Hub (sem preço hardcoded)
FAQPage apenas com Q&A visível e texto idêntico
Datas em ISO 8601 com fuso ( -03:00 )
Validação automatizada no CI sem erro crítico
Conferência por amostragem no Rich Results Test / validador de schema
Nenhum schema descrevendo conteúdo ausente na página
Anexo B — Google Business Profile e cadastro/migração das
unidades EVO
Objetivo: migrar o ecossistema de fichas locais das marcas legadas (Amigo, Ávato, Blink,
JustWeb, Sempre, GGNET/ALT, OnNet) para EVO, em escala, sem perder avaliações, fotos,
histórico e ranqueamento local. Esse é um dos ativos mais valiosos da operação e exige
método.
B.1. Princípio inegociável
A regra oficial do Google permite rebranding (mudança de nome sem criar novo perfil)
inclusive para negócios com múltiplas localizações que mudam de nome — preservando as
avaliações. Apagar e recriar perfil é tratado como negócio novo: zera avaliações, fotos e
histórico.
Portanto:
Renomear o perfil existente. Nunca apagar e recriar.
Manter mesma conta/propriedade, mesmo endereço e mesmo telefone sempre que
possível.
Atualizar site e NAP antes de renomear o perfil.
Não mudar nome, endereço, telefone e categoria ao mesmo tempo (muitas mudanças
simultâneas disparam verificação e instabilidade).
B.2. Inventário (pré-requisito — planilha-base por unidade)
Levantar, para cada ficha existente:

-- 69 of 81 --

- ID/place_id da ficha
- Marca legada (Amigo / Ávato / Blink / JustWeb / Sempre / GGNET-ALT / OnNet)
- Nome atual na ficha
- Conta Google proprietária + e-mails com acesso
- Status de verificação
- Endereço completo (NAP)
- Telefone
- Categoria principal e secundárias
- Nº de avaliações + nota média
- Site vinculado atual
- Horário de funcionamento
- Fotos existentes
- Duplicidades suspeitas
- Tipo: loja física com atendimento / ponto sem atendimento ao público
B.3. Padrão NAP e naming EVO
Nome: usar o nome real da marca + diferenciador de localização quando houver mais de
uma unidade na cidade. Ex.: EVO — Barueri (Alphaville) . Proibido keyword stuffing
(ex.: “EVO Internet Fibra Barato Barueri”) — viola diretriz e arrisca suspensão.
Endereço: preciso, com fixação no mapa quando necessário; sinalização física
permanente com a marca EVO no local (requisito do Google para endereço exibido).
Telefone: número local consistente com o do site e das demais citações.
NAP idêntico entre GBP, site ( evo.digital/lojas/... ), redes sociais, RA e diretórios.
B.4. Categorias e atributos
Categoria principal correta e consistente entre unidades (ex.: provedor de internet / loja).
Categoria certa aumenta interação no perfil.
Categorias secundárias apenas quando refletem serviços reais prestados no local.
Atributos verdadeiros (acessibilidade, formas de pagamento). Nunca atributos
enganosos.
B.5. Sequenciamento da migração (ordem segura)
1. Publicar a página oficial da unidade no site ( evo.digital/lojas/[estado]/[cidade] )
com LocalBusiness (Anexo A).
2. Configurar 301 nos sites das marcas antigas para os destinos EVO correspondentes.
3. Atualizar NAP e site vinculado no perfil.

-- 70 of 81 --

4. Renomear o perfil para o padrão EVO.
5. Aguardar estabilização da renomeação antes de ajustar categoria/atributos.
6. Atualizar logo, capa e fotos com a identidade EVO.
7. Publicar post de rebrand (“A [marca] agora é EVO”) no perfil.
8. Semear e responder o Q&A (B.9).
9. Monitorar reaparição/queda de avaliações, suspensões e duplicidades.
B.6. Operação multi-local (escala)
Centralizar tudo em grupo de localizações (location group) na conta corporativa EVO.
Usar a API do Google Business Profile e/ou upload em massa para nome, NAP,
categoria, horários, URLs e fotos — não unidade por unidade no painel.
Para grande volume, considerar plataforma de gestão de fichas (listings) com
governança e push para múltiplos diretórios, mantida sob controle da EVO.
Atualizar as URLs em massa somente depois dos 301 publicados.
B.7. Verificação (2026)
Verificação por vídeo é frequente em 2026. Preparar antecipadamente: sinalização física
com a marca EVO, materiais/branding, veículos e documentos da unidade.
Para storefront: mostrar fachada, entrada e interior. Para ponto de serviço: materiais,
equipamentos e documentos.
Tratar verificação como etapa de projeto, com responsável e prazo por unidade.
B.8. Política de avaliações (2026) — o que é proibido
Não incentivar avaliações (pagamento, desconto, brinde, pontos).
Não usar quiosque/tablet compartilhado no balcão para coletar avaliações.
Não fazer gating (pré-filtrar/triar quem é convidado a avaliar).
Não pedir que o cliente cite o nome de funcionários na avaliação.
Enforcement automatizado está removendo avaliações que violam essas regras. Coletar
avaliação de forma orgânica e responder a todas (positivas e negativas) sob a marca
EVO.
B.9. Q&A do Google Business Profile (a “FAQ” local que sobreviveu)

-- 71 of 81 --

Como o rich result de FAQ do site foi descontinuado (§10.3), o Q&A do GBP passa a ser a
principal superfície de perguntas e respostas no local:
Semear as perguntas reais que os clientes fazem (cobertura, segunda via, horário,
instalação).
Responder como proprietário (owner-verified), com texto claro e direto.
Auditar respostas enviadas por terceiros e corrigir informação errada.
Manter sincronia com a FAQ da página da unidade no site.
B.10. Vinculação de site, redes e posts
Vincular cada ficha à página oficial da unidade no site (não à home genérica).
Preencher o campo de redes sociais no GBP com os perfis oficiais EVO.
Publicar posts de rebrand e novidades pelo próprio GBP.
Atualizar logo e fotos para a identidade EVO.
B.11. Tabela de migração por marca legada
Marca
legada
Tipo
predominante Ação no GBP 	Risco principal 	Mitigação
Amigo
Internet
B2C
residencial,
lojas
Renomear para EVO,
preservar avaliações
Perda de review se
recriarem
Renomear,
nunca recriar;
inventário
antes
Ávato 	B2B/B2G Renomear; revisar
categoria
NAP divergente
entre filiais
Padronizar
NAP; categoria
coerente
Blink 	B2C/regional
Renomear;
consolidar
duplicidades
Fichas duplicadas
Merge via
suporte;
auditoria
JustWeb 	Regional 	Renomear Verificação por
vídeo
Preparar
branding físico
Sempre 	Regional 	Renomear Acesso/propriedade
da conta
Mapear donos
antes de tocar
GGNET / 	Renomear; revisar 	Endereço sem
Instalar
sinalização

-- 72 of 81 --

ALT 	Regional 	endereço 	sinalização EVO 	antes da
verificação
OnNet 	Regional 	Renomear Categoria/atributos
incorretos
Corrigir após
estabilizar
nome
Preencher por unidade real no inventário (B.2). A coluna de marca legada deve refletir a
base efetiva de cada UF (operação em 9 estados, ~236 unidades).
B.12. Checklist por unidade
Ficha inventariada (place_id, conta, dono, status)
Página oficial da unidade publicada no site (com LocalBusiness )
301 do site da marca antiga configurado
NAP e site vinculado atualizados no perfil
Perfil renomeado para padrão EVO (sem keyword stuffing)
Estabilização aguardada antes de mexer em categoria/atributos
Categoria e atributos corretos
Logo, capa e fotos com identidade EVO
Post de rebrand publicado
Q&A semeado e respondido
Redes sociais vinculadas no GBP
Verificação concluída
Avaliações preservadas (conferido antes/depois)
Sem duplicidade ativa
B.13. Riscos e mitigação
Suspensão de perfil: evitar mudanças simultâneas, keyword stuffing e endereço sem
sinalização. Acionar suporte/gerente Google antes de rebrand em massa.
Perda de avaliações: jamais recriar perfil; sempre renomear o existente.
Duplicidade: auditar e solicitar merge das fichas duplicadas.

-- 73 of 81 --

Quebra de NAP: padrão NAP único, propagado por API/listings, idêntico ao site.
Falha na transição de SEO local: 301 publicados antes de trocar URLs no GBP;
monitorar tráfego e ranqueamento local pós-rebrand.
B.14. Referências (boas práticas e regras vigentes)
Google Business Profile — Diretrizes de representação (rebranding multi-local, endereço,
categorias): https://support.google.com/business/answer/3038177
Google Business Profile — Avaliações em mudança de nome/perfil:
https://support.google.com/business/answer/3098204
Google Business Profile API (operação multi-local em escala):
https://developers.google.com/my-business
Google Search Central — Descontinuação do rich result de FAQ (maio/2026):
https://developers.google.com/search/docs/appearance/structured-data/faqpage
Anexo C — Checklists operacionais por elemento
Lista mestre de verificação, mapeada elemento a elemento do documento. Serve como
instrumento de QA e de aceite do projeto. Cada bloco corresponde a uma seção do RFP.
“Não pode faltar” marca os itens bloqueantes para go-live.
C.1. Arquitetura de domínio e subdomínios (§5)
evo.digital confirmado como domínio canônico de marca/conteúdo
Tabela de subdomínios definida (função, tipo, indexar sim/não)
Subdomínios de sistema separados do conteúdo (login, checkout, API, área logada)
Subdomínios defensivos registrados e redirecionando
Regra “produto = página em evo.digital; subdomínio só para portal/console/docs/API”
aplicada
Não pode faltar: nenhum checkout/área logada indexável no domínio principal
C.2. Arquitetura de informação e mapa do site (§6)
Árvore completa modelada e priorizada por onda
Linguagem de cliente (sem siglas internas B2C/B2B/B2G/B2S)

-- 74 of 81 --

Cinco mercados estruturados (Para Você, Empresas, Corporate, Governo, Operadoras)
Profundidade de navegação ≤ 3 cliques para páginas-chave
Não pode faltar: mapa do site ( /mapa-do-site ) publicado e no sitemap
C.3. Navegação, menu e rodapé (§7)
Menu principal enxuto e comercial
CTAs de topo (cobertura, área do cliente, assine)
Rodapé como mapa do ecossistema (produtos, atendimento, programas, institucional,
confiança, técnico)
Links de canais oficiais e redes sociais no rodapé
Não pode faltar: rodapé com link para canais oficiais e privacidade
C.4. Templates de página (§8)
Produto/solução:
H1 único, subtítulo, descrição
Benefícios, “para quem é”, “como funciona”, diferenciais
Cobertura/disponibilidade (via Offer Hub)
FAQ (ver §10.3)
CTAs corretos + links internos
Dados estruturados + data de atualização
Programa (ex.: Indique):
O que é, como funciona, quem participa, benefício, regras, regulamento
FAQ + CTA para o sistema + página de acompanhamento
Cidade/local:
H1 com cidade+serviço, cobertura, planos dinâmicos
Lojas próximas + LocalBusiness + vínculo GBP
FAQ local + canais oficiais + conteúdo único
Confiança/segurança:

-- 75 of 81 --

Canais oficiais, como identificar golpe, boletos/Pix/WhatsApp/perfis oficiais
Denúncia de fraude + FAQ + links para privacidade/compliance/atendimento
Não pode faltar: todo template indexável com title/description/H1/breadcrumb/schema
C.5. Stack técnica (§9)
Frontend Next.js + React + TS (App Router, SSR/SSG/ISR)
CMS headless enterprise com workflow, versionamento, preview, RBAC, campos de
SEO/schema
Design system real (tokens, Storybook, componentes — não template genérico)
Edge/CDN/WAF (Cloudflare Enterprise ou equivalente)
CI/CD com ambientes dev/homolog/prod, preview e rollback
API Gateway/BFF (sistemas críticos não expostos ao frontend)
E-commerce externo com repositório sob controle EVO, exportável, SAST/DAST/SCA
Não pode faltar: ambientes separados, rollback e código sob controle da EVO (anti lock-
in)
C.6. SEO técnico (§10.1)
Ver checklist completo em §10.1
Não pode faltar: SSR/SSG em 100% do indexável; plano de 301 fechado
C.7. Dados estruturados (§10.2 / Anexo A)
Ver checklist em §10.2 e A.12
Não pode faltar: Organization canônico, BreadcrumbList universal, Offer via Offer
Hub
C.8. FAQs (§10.3)
Ver checklist em §10.3
Não pode faltar: paridade schema↔conteúdo; Q&A do GBP semeado nas unidades
C.9. Google Business Profile e unidades (§10.4 / Anexo B)
Inventário de todas as fichas concluído (B.2)
Plano de rebrand multiunidade aprovado (renomear, nunca recriar)

-- 76 of 81 --

Padrão NAP + naming EVO documentado
Operação via grupo de localizações + API
Checklist por unidade (B.12) aplicado
Não pode faltar: nenhum perfil recriado; avaliações preservadas; NAP consistente
C.10. Redes sociais / NAP (§10.5)
Ver checklist em §10.5
Não pode faltar: sameAs completo + página de canais oficiais + NAP idêntico
C.11. GEO/IA (§10.6)
Ver checklist em §10.6
Não pode faltar: páginas-resposta de marca publicadas; entidade consistente
C.12. SEO local (§10.7)
Ver checklist em §10.7
Não pode faltar: conteúdo único por cidade + trava contra páginas finas
C.13. Segurança (§11.1)
WAF, DDoS, Bot Management, API Shield, rate limiting
CSP, HSTS, security headers, TLS moderno
Proteção XSS/CSRF/SSRF/injection; OWASP ASVS e API Top 10 como baseline
SAST/DAST/SCA, secret scanning, IaC scanning
Pentest antes do go-live + correção de críticos
SSO/MFA em admin; RBAC no CMS; ambientes restritos em Zero Trust
Logs de auditoria, monitoramento de anomalias, backups, plano de incidentes
Não pode faltar: pentest com críticos corrigidos; WAF ativo; MFA em administração
C.14. LGPD e consentimento (§11.2)
CMP/gestão de cookies funcional
Política de privacidade e de cookies publicadas
Portal de direitos do titular operante

-- 77 of 81 --

Registro e logs de consentimento
Minimização, finalidade por formulário, retenção definida, data mapping
Integração com DPO/encarregado; privacy by design e by default
Não pode faltar: CMP ativo + portal do titular + base legal por formulário
C.15. Antifraude e proteção de marca (§11.3)
Páginas de canais oficiais, golpes, boletos/Pix/WhatsApp/perfis oficiais
Denúncia de fraude + validação de comunicação recebida
Coerência com sameAs e com GBP
Não pode faltar: página de canais oficiais indexável e linkada globalmente
C.16. Acessibilidade (§12)
Meta WCAG 2.2 AA
Contraste, navegação por teclado, semântica, landmarks, labels, alt, foco visível
Formulários e mensagens de erro acessíveis; ARIA só quando necessário
Testes automatizados + manuais; documentação de acessibilidade
Página de atendimento acessível
Não pode faltar: AA validado nos templates-chave; navegação por teclado completa
C.17. Performance (§13)
LCP < 2,5s / INP < 200ms / CLS < 0,1 (no campo, RUM)
Performance budget por template
Imagens responsivas (AVIF/WebP), fontes otimizadas, lazy loading, code splitting
Cache na borda + pré-renderização; scripts de terceiros controlados
Lighthouse CI + monitoramento RUM + relatórios periódicos
Não pode faltar: Core Web Vitals dentro das metas nos templates-chave
C.18. Analytics e mensuração (§14)
GA4 + GTM Server-Side + BigQuery + dashboards
CMP integrado ao disparo de tags (consent mode)

-- 78 of 81 --

Eventos mínimos (§14.2) implementados e validados
Parâmetros mínimos (§14.3) populados; cep_hash sem PII
Integração com CRM/Salesforce
Não pode faltar: eventos de cobertura, lead e checkout instrumentados e testados
C.19. Conteúdo editorial (§15)
Tom de voz aplicado (claro, direto, sem jargão nem promessa vazia)
Hubs de conteúdo criados
Volume mínimo de lançamento atingido (home, mercados, 30+ produtos, setores,
institucional, atendimento/confiança, programas, migração, locais, blog, ajuda)
Sem lorem ipsum; metadados únicos; revisão jurídico/compliance onde necessário
Não pode faltar: zero placeholder em produção; páginas-resposta de marca prontas
C.20. Migração de marcas (§16)
Inventário de URLs antigas (todas as marcas e sites adquiridos)
301 planejados, versionados e testados
Páginas obrigatórias publicadas ( /agora-somos-evo , /[marca]-agora-evo , “o que
muda/não muda”, canais oficiais)
Mensagem padrão aplicada
Search Console e Google Business Profile atualizados (Anexo B)
Monitoramento de queda de tráfego + plano de comunicação ao cliente
Não pode faltar: 301 testados + páginas de migração + GBP renomeado sem perda de
review
C.21. Integrações (§17)
Mapa de integrações documentado (CMS, Offer Hub, Gateway, CRM/Salesforce, SAP,
BSS/OSS, Billing, e-commerce, área do cliente, atendimento, WhatsApp, GBP, analytics,
data lake, app, status, parceiros, fornecedores, RI, carreiras, CMP, segurança)
Contratos de API (OpenAPI), versionamento e tratamento de erro padronizado
Não pode faltar: validação server-side de preço/oferta; nenhum sistema crítico exposto
ao frontend

-- 79 of 81 --

C.22. Entregáveis da contratada (§18)
Estratégia e arquitetura (AI, sitemap, SEO/GEO, conteúdo, migração, subdomínios,
redirecionamento, governança)
UX/UI (wireframes, protótipos, design system, templates, responsivo, acessibilidade,
docs)
Tecnologia (frontend, CMS, APIs, infra, CI/CD, ambientes, segurança, observabilidade,
testes, docs)
Conteúdo (modelos, redação SEO, páginas, metadados, FAQs, structured data,
guidelines)
Go-live (plano, checklists técnico/SEO/segurança/LGPD/acessibilidade, monitoramento,
rollback, treinamento)
Não pode faltar: documentação completa + treinamento + transferência de
conhecimento (anti lock-in)
C.23. Go-live e critérios de aceite (§19)
Build sem erro; testes passando; Lighthouse e CWV nas metas
SEO sem erro crítico; schema válido; sitemap/robots/canonicals corretos
Segurança validada (pentest, WAF, headers, MFA)
CMS e preview funcionais; integrações testadas; logs e monitoramento ativos
Conteúdo completo, sem duplicação indevida, aprovado por jurídico/compliance quando
aplicável
Plano de rollback testado
Não pode faltar: checklist de go-live assinado por dono técnico, editorial e de negócio
C.24. Governança (§22)
Conselhos/ritos definidos (Brand, Digital, Product, Content, Security & Trust, Migration
Office, Performance Review)
Cada página crítica com dono de negócio, dono editorial, dono técnico, frequência de
revisão, status e data
Cadência de revisão de SEO/GEO, schema, NAP e GBP
Não pode faltar: matriz de donos por página crítica preenchida antes do go-live

-- 80 of 81 --

Encerramento dos anexos
Estes anexos transformam o RFP de uma lista de “o que” em um padrão de “como, com o
que entregar e o que não pode faltar”, com checklists de aceite por elemento. Dois pontos
merecem destaque por terem mudado o jogo recentemente: (1) o rich result de FAQ do
Google foi descontinuado — FAQ agora é ativo de GEO/IA, não de SERP; (2) a troca de marca
no Google Business Profile, feita corretamente como renomeação multiunidade, preserva o
ativo de avaliações que a operação construiu sob Amigo, Blink, Ávato e demais — e fazê-la
errado o destrói. Ambos estão incorporados ao escopo e aos critérios de aceite.

-- 81 of 81 --

