Pipeline de dados para gerar páginas de cobertura de fibra óptica com SEO programático

Um provedor regional em Minas Gerais precisava escalar a presença digital de 120 municípios onde já tinha infraestrutura de fibra óptica, mas o site possuía apenas 15 páginas estáticas de cobertura. A equipe de marketing tentava criar páginas manualmente: cada uma levava 4 horas entre pesquisa de CEPs, validação com engenharia, redação e publicação. Em seis meses, cobriram 40 bairros. O gargalo não era a redação — era a ausência de um pipeline que transformasse dados de rede em páginas publicáveis com garantia técnica.

O cenário se repete em provedores de todos os portes: a base de endereços dos Correios não conversa com a malha de splitters no PostGIS, que não conversa com o CRM de vendas, que não conversa com o CMS. O resultado são páginas desatualizadas, cobertura fantasma que gera reclamação no Reclame Aqui, e oportunidades perdidas em bairros onde a fibra já chegou mas o Google não sabe.

Este artigo detalha a arquitetura de um pipeline de dados ponta a ponta: da ingestão de fontes heterogêneas à publicação de milhares de páginas validadas tecnicamente, com monitoramento contínuo de qualidade. A abordagem privilegia a confiabilidade do dado sobre a velocidade de geração — porque uma página errada custa mais caro que dez páginas não publicadas.

Fontes de dados e normalização

O pipeline começa pela ingestão de cinco fontes primárias. A base de logradouros dos Correios (DNE) fornece a espinha dorsal de endereçamento com CEP, tipo de logradouro, bairro e município. Shapefiles do IBGE (setores censitários e malha municipal) entram para geocodificação precisa e agregação por bairro. A Anatel disponibiliza a base de outorgas e infraestrutura licenciada. A concessionária de energia local cede cadastro de postes e dutos via convênio de compartilhamento. Por fim, o OSS/BSS do provedor exporta a topologia ativa: OLTs, splitters, portas livres e coordenadas GPS dos equipamentos de campo.

A normalização é o estágio mais crítico. Endereços brasileiros sofrem com variações: “Rua das Flores”, “R. das Flores”, “Rua Das Flores”, “R Das Flores” — todas referem-se ao mesmo logradouro. Use a biblioteca libpostal (via pypostal ou API gerenciada) para parsar e padronizar cada endereço em componentes atômicos: house_number, road, neighbourhood, city, state, postcode. Armazene a versão canônica (lowercase, sem acentos, abreviações expandidas) como chave primária de join. Crie uma tabela enderecos_normalizados com endereco_id, versao_original, versao_canonica, lat, lon, cep, bairro_id, cidade_id, uf.

Para geocodificação em lote, evite APIs pagas por requisição. Carregue a malha de endereços do OpenAddresses Brasil ou a base do IBGE no PostGIS e faça ST_DWithin com buffer de 50 metros. Endereços não geocodificados entram em fila de revisão manual — a meta é taxa de sucesso > 98%.

Validação técnica de cobertura em três camadas

Gerar página para endereço sem fibra real é risco jurídico e reputacional. A validação ocorre em cascata, cada camada filtrando falsos positivos da anterior.

Camada 1 — Geográfica (raio de splitter): No PostGIS, cada splitter ativo vira um círculo de 300 metros (GPON) ou 500 metros (XGS-PON) via ST_Buffer(geography, 300). Endereços dentro do buffer recebem splitter_id candidato. Use índice GiST para performance: CREATE INDEX idx_splitter_buffer ON splitters USING GIST (ST_Buffer(geom, 300)).

Camada 2 — Lógica (capacidade de porta): Junte o splitter_id candidato com a tabela de portas da OLT. Um splitter 1:32 tem 32 portas; se portas_ocupadas >= 30, marque como capacidade_critica. Só prossiga se portas_livres > 0. Essa verificação evita vender cobertura onde a OLT já está saturada.

Camada 3 — Operacional (viabilidade de drop): A API de ordem de serviço da equipe de campo recebe o endereço e retorna: viavel (sim/não), distancia_drop_metros, tipo_passagem (aérea/subterrânea), necessita_licenca (sim/não), prazo_dias_uteis. Endereços com viavel = não ou necessita_licenca = sim sem licença emitida ficam em cobertura_pendente — não geram página pública.

Apenas endereços que passam nas três camadas recebem status_cobertura = 'disponivel' e entram no lote de geração de páginas.

Arquitetura do pipeline de geração

O pipeline roda em Airflow (ou Prefect/Dagster) com DAGs diárias para atualização incremental e semanais para carga completa. A estrutura modular permite reprocessar apenas o que mudou.

dag = DAG(
    'pipeline_cobertura_fibra',
    schedule_interval='0 3 * * *',  # 03h diário
    catchup=False,
    max_active_runs=1
)

ingest_dne = PythonOperator(
    task_id='ingest_dne',
    python_callable=ingest_dne_task,
    dag=dag
)

normalize_enderecos = PythonOperator(
    task_id='normalize_enderecos',
    python_callable=normalize_enderecos_task,
    dag=dag
)

geocode_batch = PythonOperator(
    task_id='geocode_batch',
    python_callable=geocode_batch_task,
    dag=dag
)

validate_cobertura = PythonOperator(
    task_id='validate_cobertura',
    python_callable=validate_cobertura_task,
    dag=dag
)

generate_pages = PythonOperator(
    task_id='generate_pages',
    python_callable=generate_pages_task,
    dag=dag
)

publish_cms = PythonOperator(
    task_id='publish_cms',
    python_callable=publish_cms_task,
    dag=dag
)

update_sitemap = PythonOperator(
    task_id='update_sitemap',
    python_callable=update_sitemap_task,
    dag=dag
)

ingest_dne >> normalize_enderecos >> geocode_batch >> validate_cobertura >> generate_pages >> publish_cms >> update_sitemap

A task generate_pages usa Jinja2 templates com herança: base_cobertura.html → cobertura_logradouro.html / cobertura_bairro.html / cobertura_cidade.html. Cada template recebe um dicionário de contexto com dados estruturados: disponibilidade, tecnologia, preço da região, depoimentos de clientes do mesmo bairro (anônimos), FAQ dinâmico baseado em tickets de suporte da região, e schema.org completo.

SEO técnico para indexação em escala

Milhares de páginas exigem arquitetura de indexação deliberada. O sitemap index é particionado por UF: sitemap-cobertura-sp.xml, sitemap-cobertura-mg.xml, etc. Cada sitemap lista até 50.000 URLs com lastmod = data de ativação do splitter mais recente naquela URL. changefreq = weekly para logradouros, monthly para bairros.

Implemente robots.txt dinâmico que bloqueia /cobertura/*/pendente/ (áreas em validação) e /cobertura/*/sem-cobertura/ (retornam 404). Use X-Robots-Tag: noindex via header HTTP para páginas de transição — mais confiável que meta tag.

Estrutura de URL canônica:

• Logradouro: /cobertura/sp/sao-paulo/vila-madalena/rua-harmonia/
• Bairro: /cobertura/sp/sao-paulo/vila-madalena/
• Cidade: /cobertura/sp/sao-paulo/

Redirecione variações (com/sem barra final, maiúsculas) para a canônica via 301 no CDN/edge. Implemente hreflang apenas se houver versão em inglês/espanhol — não duplique para PT-BR.

O schema.org JSON-LD em cada página:

{
  "@context": "https://schema.org",
  "@type": "InternetServiceProvider",
  "name": "Provedor Fibra X",
  "areaServed": {
    "@type": "GeoCircle",
    "geoMidpoint": {"@type": "GeoCoordinates", "latitude": -23.55, "longitude": -46.63},
    "geoRadius": "300"
  },
  "serviceType": "Fiber to the Home (FTTH)",
  "offers": {
    "@type": "Offer",
    "availability": "https://schema.org/InStock",
    "priceSpecification": {"@type": "PriceSpecification", "price": "149.90", "priceCurrency": "BRL"}
  }
}

Monitoramento contínuo e qualidade de dado

O pipeline não acaba na publicação. Quatro métricas norteiam a saúde do sistema:

1. Taxa de endereços não geocodificados — alerta se > 2% do lote diário. Indica problema na base DNE ou no shapefile de referência.
2. Cobertura fantasma — amostragem semanal de 200 páginas publicadas: equipe de campo visita ou liga para o endereço. Meta: 0% de falsos positivos. Qualquer ocorrência dispara investigação de root cause (splitter desativado? porta queimada? drop não viável?).
3. Latência de geração — tempo entre validate_cobertura e publish_cms concluído. Alerta se > 30 minutos. Gargalos costumam estar no render de template Jinja2 para 50k+ páginas — resolva com geração assíncrona em lote (Celery + Redis) e publicação via API em massa do CMS.
4. Tráfego orgânico por template — compare sessões orgânicas de páginas de logradouro vs bairro vs cidade no GA4/Search Console. Queda > 15% em 7 dias em qualquer template dispara auditoria de Core Web Vitals e indexação.

Dashboards no Grafana consomem métricas do Prometheus (instrumentação customizada nas tasks Airflow) e logs do CloudWatch/ELK. Alertas no PagerDuty/Slack com runbooks vinculados.

Integração com vendas e atendimento

Páginas de cobertura não são fim em si mesmas — alimentam o funil comercial. Cada página de logradouro expõe um botão “Verificar disponibilidade exata” que chama a API de validação em tempo real (camadas 1 a 3) e retorna: disponível, agendar visita técnica, ou indisponível com motivo. O lead cai no CRM com origem = 'pagina_cobertura_logradouro', endereco_id, splitter_id, capacidade_atual.

Essa integração permite relatórios de conversão por splitter: quais equipamentos geram mais leads, quais têm alta taxa de “indisponível” (sinal de saturação), e onde investir em expansão. O time de engenharia passa a receber demanda priorizada por receita potencial, não por ordem de chamado.

A solução Pagi de SEO complementa essa arquitetura ao automatizar a geração e indexação de páginas técnicas em escala, mantendo a consistência de dados estruturados e performance de Core Web Vitals across milhares de URLs.

Conclusão prática

Um pipeline de dados para páginas de cobertura de fibra óptica transforma infraestrutura física em ativo digital rastreável. A chave não é a tecnologia de geração de páginas — é a validação técnica rigorosa antes da publicação, a arquitetura de indexação pensada para milhares de URLs, e o loop de feedback entre campo, dado e página. Comece com um município piloto, valide cada camada com a equipe de campo, meça a conversão de lead qualificado, e escale com confiança. O Google recompensa precisão; o cliente recompensa verdade.

Checklist prático

Perguntas frequentes