Modelo de RFP para Redesign de Site: Escopo de Migração e Preservação de SEO
RFP de Redesign de Website com Foco em SEO: O Guia Completo para 2026
Revisei centenas de RFPs de redesign de website ao longo dos anos. A maioria deles é terrível. Eles obcedam por paletas de cores e animações de imagens hero enquanto ignoram completamente aquilo que destruirá seu tráfego orgânico: escopo de migração e preservação de SEO. O resultado? Um website brilhante e novo que perde 30-60% do seu tráfego de busca dentro de semanas após o lançamento.
Isto não é teórico. Fomos contratados várias vezes para corrigir redesigns que deram errado porque o RFP original não incluía uma única linha sobre mapeamento de redirecionamentos, preservação de estrutura de URLs ou metas de Core Web Vitals. Um cliente perdeu $2.3M em receita orgânica anual porque sua agência anterior tratou SEO como um detalhe secundário.
Se você já sabe que precisa de ajuda e quer pular para frente, envie seu RFP e faremos uma revisão com uma perspectiva centrada em SEO.
Aqui está o template de RFP que gostaria que toda organização usasse ao planejar um redesign de website em 2026. Ele foi construído a partir de projetos reais, falhas reais e recuperações reais.
Índice
- Por que a Maioria dos RFPs de Redesign Fracassa em SEO
- A Estrutura Completa do Template RFP
- Seção 1: Visão Geral do Projeto e Contexto Empresarial
- Seção 2: Escopo de Migração Técnica
- Seção 3: Requisitos de Preservação de SEO
- Seção 4: Especificações de Migração de Conteúdo
- Seção 5: Alvos de Performance e Core Web Vitals
- Seção 6: Critérios de Avaliação de Fornecedores
- Seção 7: Timeline, Marcos e Critérios de Aceitação
- Erros Comuns de RFP que Matam Tráfego Orgânico
- Considerações de Tecnologia para 2026
- FAQ
Por que a Maioria dos RFPs de Redesign Fracassa em SEO
O RFP típico de redesign lê como uma lista de desejos para uma agência de design. Terá páginas sobre diretrizes de marca, fluxos de aprovação de stakeholders e responsividade mobile. Tudo importante. Mas preservação de SEO? Talvez um bullet point que diz "manter rankings de busca atuais" sem zero especificações sobre como.
Aqui está o que dá errado:
- Nenhum requisito de auditoria de baseline. Você não pode preservar aquilo que não mediu. Se seu RFP não exigir uma auditoria de SEO pré-migração, você está voando às cegas.
- Estrutura de URL tratada como decisão de design. Arquitetos de informação mudam URLs para corresponder à nova navegação sem perceber que estão quebrando milhares de páginas indexadas.
- Mapeamento de redirecionamento é um detalhe secundário. Fica amontoado nas últimas duas semanas antes do lançamento, feito por um dev junior com uma planilha.
- Nenhum plano de monitoramento pós-lançamento. A agência lança, comemora e segue em frente. Enquanto isso, seus rankings estão desabando.
Um estudo de 2025 do Ahrefs descobriu que 74% dos websites que sofreram um redesign major experimentaram perda significativa de tráfego orgânico, com o tempo médio de recuperação sendo 6-12 meses. Para sites que incluíram specs de migração de SEO detalhadas em seu RFP, esse número caiu para 21%.
A diferença não é sorte. É planejamento.
A Estrutura Completa do Template RFP
Aqui está uma visão geral do que um RFP de redesign apropriado deve conter quando preservação de SEO é uma prioridade:
| Seção | Propósito | Contagem de Páginas Típica |
|---|---|---|
| Visão Geral do Projeto | Contexto empresarial, objetivos, KPIs | 2-3 páginas |
| Escopo de Migração Técnica | Plataforma, hospedagem, infraestrutura | 3-5 páginas |
| Requisitos de Preservação de SEO | Redirecionamentos, schema, indexação | 4-6 páginas |
| Specs de Migração de Conteúdo | Tipos de conteúdo, taxonomia, metadados | 3-4 páginas |
| Alvos de Performance | Core Web Vitals, tempos de carregamento | 2-3 páginas |
| Critérios de Avaliação de Fornecedores | Rubrica de pontuação, referências | 2-3 páginas |
| Timeline e Aceitação | Marcos, critérios de QA | 2-3 páginas |
| Total | 18-27 páginas |
Sim, é mais do que a maioria das organizações escreve. Esse é o ponto. Cada página que você pula aqui custa meses de recuperação de tráfego depois.
Seção 1: Visão Geral do Projeto e Contexto Empresarial
É aqui que você estabelece o palco. Não apenas descreva o que você quer. Explique por que você está redesenhando e o que sucesso parece em termos mensuráveis.
O que Incluir
## 1. Visão Geral do Projeto
### 1.1 Histórico Organizacional
- Descrição da empresa, indústria, público-alvo
- URL do website atual e stack de tecnologia
- Tráfego orgânico anual (sessões, usuários, atribuição de receita)
### 1.2 Objetivos de Redesign (Classificados por Prioridade)
1. [ex., Melhorar taxa de conversão de tráfego orgânico em 25%]
2. [ex., Reduzir tempo de carregamento de página para menos de 2 segundos]
3. [ex., Migrar de WordPress para arquitetura headless CMS]
4. [ex., Preservar 95%+ do tráfego de busca orgânico atual]
### 1.3 Métricas de Sucesso
- Tráfego orgânico dentro de 90 dias após lançamento: ≥95% do baseline pré-lançamento
- Core Web Vitals: Todas as páginas passando em mobile e desktop
- Páginas indexadas: 100% das páginas alvo indexadas dentro de 60 dias
- Taxa de conversão: ≥ baseline atual dentro de 90 dias
### 1.4 Faixa de Orçamento
- Orçamento total do projeto: $XX,000 - $XX,000
- Orçamento de manutenção contínua (mensal): $X,000 - $X,000
A coisa crítica aqui: coloque essa métrica de preservação de tráfego orgânico bem nos objetivos. Torne-a uma obrigação contratual, não algo bom de ter. Se um fornecedor lê seu RFP e não vê SEO mencionado até página 15, eles equalizarão o projeto adequadamente -- sem expertise em SEO.
Seção 2: Escopo de Migração Técnica
Esta seção define os limites do que está mudando. Seja explícito sobre o estado atual e o estado final desejado.
Requisitos de Plataforma e Arquitetura
## 2. Escopo de Migração Técnica
### 2.1 Estado Atual
- CMS: [ex., WordPress 6.x com WooCommerce]
- Hospedagem: [ex., WP Engine, plano Growth]
- CDN: [ex., Cloudflare Pro]
- Total de páginas: [ex., 4,200 páginas indexadas por Google Search Console]
- Total de URLs (incluindo parâmetros): [ex., ~12,000]
- Integrações de terceiros: [liste todas]
### 2.2 Estado Final Desejado
- CMS: [ex., headless CMS (Sanity, Contentful, ou equivalente)]
- Frontend: [ex., Next.js ou Astro com SSR/SSG]
- Hospedagem: [ex., Vercel, Netlify, ou AWS]
- CDN: [ex., Rede Edge Vercel ou Cloudflare]
### 2.3 Tipo de Migração
- [ ] Mesmo domínio, mesma plataforma (apenas redesign visual)
- [ ] Mesmo domínio, nova plataforma (re-plataforma)
- [ ] Mudança de domínio + nova plataforma (risco mais alto)
- [ ] Consolidação de subdomínio
Se você está considerando uma migração para arquitetura headless -- que é cada vez mais comum para redesigns focados em performance -- você vai querer um fornecedor com experiência nessa transição. Escrevemos extensivamente sobre nossa abordagem para desenvolvimento de CMS headless e as considerações de SEO específicas envolvidas.
Especificações de Infraestrutura
Inclua requisitos de renderização server-side, estratégia de cache edge e como conteúdo dinâmico será tratado. Uma configuração headless com um framework como Next.js ou Astro pode melhorar dramaticamente Core Web Vitals, mas apenas se a estratégia de renderização estiver correta.
Seção 3: Requisitos de Preservação de SEO
Este é o coração do RFP. Não seja vago aqui. Especifique exatamente o que você espera.
3.1 Auditoria de SEO Pré-Migração
### 3.1 Requisitos de Auditoria Pré-Migração
O fornecedor selecionado deve completar e entregar o seguinte antes
de qualquer desenvolvimento começar:
1. **Crawl completo do site existente** usando Screaming Frog, Sitebulb, ou
equivalente (capacidade mínima de 50,000 URLs)
2. **Inventário de páginas com melhor desempenho**: Todas as páginas gerando
tráfego orgânico (limiar mínimo: 10 sessões/mês nos 12 meses anteriores)
3. **Exportação de perfil de backlinks**: Todas as páginas com backlinks
externos (Ahrefs, Semrush, ou Majestic)
4. **Posições de ranking atuais**: Palavras-chave alvo com posições SERP
atuais (top 100 mínimo)
5. **Baseline de SEO técnico**: Erros de crawl, páginas órfãs, problemas de
canonical, tags hreflang, inventário de dados estruturados
6. **Mapa de estrutura de links internos**: Visualização da distribuição de
equity de link interno atual
3.2 Requisitos de Mapeamento de Redirecionamento
Fomos convocados para um cliente Fortune 500 no ano passado. Sua agência anterior havia usado redirecionamentos wildcard para mapear uma subpasta inteira /resources/ para uma única landing page. Parecia arrumado na planilha. Na prática, matou 340 páginas indexadas que estavam gerando $18K/mês em receita atribuída a orgânico. Cada uma daquelas URLs precisava de um redirecionamento 1:1 para seu contraparte real no novo site.
Seja implacavelmente específico:
### 3.2 Mapeamento de Redirecionamento
1. **Mapa de redirecionamento 1:1** para cada URL retornando status 200
no site atual
2. Mapa de redirecionamento deve ser entregue como CSV com colunas:
- URL de origem (atual)
- URL de destino (novo)
- Código de status HTTP (301 ou 308)
- Tipo de página (produto, blog, categoria, etc.)
- Sessões orgânicas mensais (12 meses anteriores)
- Número de domínios referenciadores
3. **Nenhuma cadeia de redirecionamento**: Máximo um salto de URL antiga para URL nova
4. **Nenhum redirecionamento wildcard** sem aprovação explícita. Cada
redirecionamento de padrão deve ser documentado com URLs de exemplo.
5. Mapa de redirecionamento deve ser **testado em staging** com tooling
automatizada antes de implantação em produção
6. Todos os redirecionamentos devem ser implementados no **nível de
servidor/edge**, não via JavaScript
3.3 Requisitos de SEO On-Page
### 3.3 Preservação de SEO On-Page
1. **Title tags**: Migre title tags existentes para todas as páginas indexadas.
Qualquer mudança deve ser documentada e aprovada.
2. **Meta descriptions**: Migre meta descriptions existentes.
CMS deve suportar customização por página.
3. **H1 tags**: Um H1 por página, correspondendo à intenção de palavra-chave alvo
4. **Schema markup**: Migre todos os dados estruturados existentes.
Novas páginas devem incluir tipos de schema apropriados.
Mínimo: Organization, BreadcrumbList, Article/Product conforme aplicável
5. **Open Graph e Twitter Cards**: Todas as páginas devem ter metadados
sociais completos
6. **Tags canonical**: Canonicals auto-referenciadores em todas as páginas indexáveis.
Fornecedor deve documentar estratégia de canonical para conteúdo
filtrado/paginado.
7. **XML sitemaps**: Auto-gerados, divididos por tipo de conteúdo,
máximo 50,000 URLs por arquivo, enviados ao Google Search Console
dentro de 24 horas após lançamento
8. **Robots.txt**: Deve ser revisado e aprovado pré-lançamento.
Nenhum noindex/nofollow acidental em produção.
Não consigo estressar esse último ponto o suficiente. Pessoalmente vi três lançamentos principais onde alguém deixou uma tag noindex meta de staging na build de produção. Um site perdeu seu índice inteiro do Google por 11 dias.
3.4 SEO Internacional (Se Aplicável)
Se você tem um site multi-linguagem ou multi-região, adicione requisitos específicos para implementação de hreflang, estratégia ccTLD vs. subdiretório e como o novo CMS tratará conteúdo locale-específico.
Seção 4: Especificações de Migração de Conteúdo
Inventário de Tipo de Conteúdo
Crie uma tabela de cada tipo de conteúdo e seu status de migração:
| Tipo de Conteúdo | Contagem Atual | Ação de Migração | Prioridade |
|---|---|---|---|
| Posts de blog | 847 | Migre todos com tráfego orgânico >0 | Alta |
| Páginas de produto | 234 | Migre todas, redesenhe template | Alta |
| Páginas de categoria | 45 | Migre, consolide onde anotado | Alta |
| Landing pages | 32 | Migre com designs atualizados | Média |
| Páginas de Ajuda/FAQ | 120 | Audit e consolide | Média |
| Comunicados de imprensa (pré-2023) | 200+ | 301 para página de categoria relevante | Baixa |
| Páginas de autor | 15 | Migre com bios atualizadas | Baixa |
Taxonomia e Estrutura de URL
### 4.2 Regras de Estrutura de URL
1. **Estrutura de URL preferida**: Corresponda estrutura existente onde possível
- Blog: /blog/[slug]
- Produtos: /products/[category]/[slug]
- Páginas: /[slug]
2. **Convenções de URL**:
- Apenas minúsculas
- Hífens como separadores (sem underscores)
- Nenhuma barra final (ou sempre barras finais -- escolha uma)
- Nenhuma extensão de arquivo (.html, .php)
- Nenhum ID de sessão ou parâmetros de rastreamento em URLs indexáveis
3. **Qualquer mudança de estrutura de URL** deve ser acompanhada de mapa
de redirecionamento atualizado e aprovada por [stakeholder designado]
Seção 5: Alvos de Performance e Core Web Vitals
Os sinais de page experience do Google continuam importando em 2026. Seu RFP deve estabelecer alvos de performance específicos e mensuráveis:
| Métrica | Alvo (Mobile) | Alvo (Desktop) | Ferramenta de Medição |
|---|---|---|---|
| Largest Contentful Paint (LCP) | ≤ 2.0s | ≤ 1.5s | CrUX / PageSpeed Insights |
| Interaction to Next Paint (INP) | ≤ 150ms | ≤ 100ms | CrUX / PageSpeed Insights |
| Cumulative Layout Shift (CLS) | ≤ 0.05 | ≤ 0.05 | CrUX / PageSpeed Insights |
| Time to First Byte (TTFB) | ≤ 400ms | ≤ 200ms | WebPageTest |
| Peso Total de Página | ≤ 1.5MB | ≤ 2.0MB | Lighthouse |
| Lighthouse Performance Score | ≥ 90 | ≥ 95 | Lighthouse CI |
### 5.2 Requisitos de Testes de Performance
1. Lighthouse CI deve ser integrado no pipeline de deploy
com thresholds de pontuação mínima como gate checks
2. Real User Monitoring (RUM) deve ser implementado pré-lançamento
(ex., Vercel Analytics, SpeedCurve, ou equivalente)
3. Performance budget deve ser documentado e executado para:
- Tamanho do bundle JavaScript (total e por-rota)
- Pipeline de otimização de imagem (WebP/AVIF com fallbacks)
- Estratégia de carregamento de fonte (preload, font-display: swap)
4. Fornecedor deve fornecer relatório de comparação de performance:
site atual vs. site novo através de 20 páginas representativas
Frameworks modernos tornam esses alvos alcançáveis. Rotineiramente alcançamos LCP sub-1s em builds Astro e sub-1.5s em projetos Next.js com otimização apropriada. Mas você precisa estabelecer essas expectativas no RFP, ou receberá o que quer que seja o padrão do fornecedor.
Seção 6: Critérios de Avaliação de Fornecedores
Aqui está uma rubrica de pontuação que você pode adaptar:
| Critério | Peso | Pontuação (1-5) |
|---|---|---|
| Experiência em migração de SEO (case studies com dados de tráfego) | 25% | |
| Abordagem de arquitetura técnica | 20% | |
| Histórico de otimização de performance | 15% | |
| Metodologia de migração de conteúdo | 15% | |
| Composição de equipe (recurso dedicado de SEO?) | 10% | |
| Realismo de timeline e marcos | 10% | |
| Transparência de preços | 5% |
Note que experiência em migração de SEO carrega o peso mais alto. Isso é intencional. Um website bonito que perde tráfego é uma responsabilidade, não um asset.
Perguntas para Fazer Referências de Fornecedor
- "Qual porcentagem de tráfego orgânico foi preservada 90 dias após lançamento?"
- "Houve quaisquer drops inesperados de ranking? Como foram tratados?"
- "Como foi gerenciado o processo de mapeamento de redirecionamento?"
- "O fornecedor forneceu monitoramento de SEO pós-lançamento?"
Se um fornecedor não pode fornecer pelo menos duas referências onde possam responder essas perguntas com números específicos, isso é uma bandeira vermelha.
Se você está ativamente escrevendo seu RFP agora e quer olhos de especialista nele antes de sair, envie-nos seu RFP e daremos feedback honesto sobre o que está faltando.
Seção 7: Timeline, Marcos e Critérios de Aceitação
Um redesign realista com migração de SEO apropriada leva 12-20 semanas para um site de médio porte (1,000-10,000 páginas). Qualquer pessoa prometendo menos está cortando cantos em algum lugar.
### 7.1 Schedule de Marco
| Fase | Duração | Entregáveis | Gate de Aceitação |
|-------|----------|-------------|------------------|
| Discovery & Audit | 2-3 semanas | SEO audit, inventário de conteúdo, avaliação técnica | Aprovação de stakeholder |
| Strategy & Architecture | 2-3 semanas | IA, mapeamento de URL, plano de redirect, wireframes | Revisão de SEO + aprovação |
| Design | 3-4 semanas | Design system, templates de página-chave | Aprovação de marca + UX |
| Development | 4-6 semanas | Site de staging funcional | QA técnico aprovado |
| Content Migration | 2-3 semanas | Todos conteúdo migrado para staging | QA de conteúdo + SEO |
| Pre-Launch QA | 1-2 semanas | Teste de redirect completo, comparação de crawl, audit de performance | Aprovação de SEO obrigatória |
| Launch | 1 dia | Cutover de DNS, ativação de redirect | Monitoramento de war room |
| Post-Launch Monitoring | 4-8 semanas | Relatórios de tráfego semanais, monitoramento de crawl, cobertura de índice | Comparação de tráfego de 90 dias |
### 7.2 Checklist Pré-Lançamento (Must-Pass)
- [ ] Todos redirecionamentos 301 testados e verificados (automatizado)
- [ ] XML sitemap gerado e validado
- [ ] Robots.txt revisado (nenhum bloco acidental)
- [ ] Todas páginas renderizam corretamente sem JavaScript (para crawlers)
- [ ] Schema markup validado via Google Rich Results Test
- [ ] Tags canonical verificadas em todas páginas indexáveis
- [ ] Core Web Vitals passando em páginas representativas
- [ ] Propriedade Google Search Console verificada para novo site
- [ ] Rastreamento de analytics verificado em todos templates de página
- [ ] Nenhuma tag noindex em páginas de produção
Essa última checklist deve ser um requisito contratual. Lançamento não acontece até cada caixa estar marcada.
Erros Comuns de RFP que Matam Tráfego Orgânico
Depois de anos fazendo isso, aqui estão os padrões que vejo repetidos:
1. "Lidaremos com redirecionamentos após lançamento." Não. Redirecionamentos devem estar em lugar no momento do lançamento. A cada hora sem eles, Google está descobrindo 404s e desvalorizando suas páginas.
2. "Estamos apenas mudando o design, não o conteúdo." Mudar templates muda como Google vê seu conteúdo. Diferentes estruturas de heading, links internos alterados, novo JavaScript rendering -- tudo afeta rankings.
3. "Nosso dev conhece SEO." Talvez. Mas conhecer SEO e ter executado uma migração de site são coisas muito diferentes. Peça por experiência específica de migração.
4. "Vamos apenas redirecionar tudo para a homepage." Isso é funcionalmente o mesmo que um 404 nos olhos do Google. É um soft 404. Não faça isso.
5. "Queremos limpar nossa estrutura de URL enquanto estamos nisso." Isso aumenta dramaticamente o risco de migração. Se você deve mudar URLs, está bem. Mas entenda que está adicionando semanas de trabalho de mapeamento de redirect e aceitando risco mais alto.
Considerações de Tecnologia para 2026
A tecnologia que você escolhe afeta diretamente a complexidade de migração de SEO. Aqui está o que estamos vendo:
| Abordagem | Pros de SEO | Contras de SEO | Melhor Para |
|---|---|---|---|
| Next.js (App Router) | SSR/SSG, ótimo CWV, otimização Image nativa | Hydration pode afetar INP se mal configurado | Sites dinâmicos, e-commerce |
| Astro | Praticamente zero JS por padrão, excelente CWV | Menos ecosistema para interatividade complexa | Sites ricos em conteúdo, blogs |
| WordPress (headless) | CMS familiar, ecossistema massivo de plugins | Performance depende muito do frontend | Times investidos em workflows WP |
| Webflow | Visual builder, lançamentos rápidos | Customização de SEO limitada, vendor lock-in | Sites de marketing com times pequenos |
| WordPress Tradicional | Tooling de SEO maduro (Yoast, Rank Math) | Teto de performance, overhead de segurança | Projetos com orçamento limitado |
Descobrimos que arquiteturas headless com Next.js ou Astro pareadas com um CMS headless como Sanity ou Contentful dão a melhor combinação de experiência de editor e performance de SEO. Mas a migração de um CMS tradicional para headless adiciona complexidade que seu RFP precisa contabilizar.
Se você está avaliando fornecedores para esse tipo de projeto, sempre estamos felizes em conversar pelas considerações técnicas. Você pode verificar nossos preços ou nos contatar diretamente -- sem obrigação, genuinamente adoramos nerdear sobre esse assunto.
FAQ
Quanto tempo leva um website redesign típico com preservação de SEO?
Para um site de médio porte (1,000-10,000 páginas), espere 12-20 semanas do kickoff ao lançamento, mais 8-12 semanas de monitoramento pós-lançamento. Sites com mais de 10,000 páginas ou funcionalidade e-commerce complexa podem levar 6-9 meses. Apressar a timeline é o preditor único mais importante de perda de tráfego.
Que porcentagem de tráfego orgânico devemos esperar reter após um redesign?
Com planejamento apropriado de migração, você deve reter 90-100% de tráfego orgânico dentro de 90 dias. Alguma flutuação temporária (uma queda de 10-15%) nas primeiras 2-4 semanas é normal conforme Google rastreia novamente e reindeixa. Se você vê uma queda de 30%+ que persiste além de 4 semanas, algo deu errado com a migração.
Devemos incluir requisitos de SEO no RFP principal ou criar um documento separado?
Inclua-os no RFP principal. Quando requisitos de SEO vivem em um documento separado, eles são tratados como opcionais. Fornecedores precisam ver esses requisitos ao lado do escopo de design e desenvolvimento para que possam equalize e orçem adequadamente.
Quanto custa um website redesign com migração de SEO apropriada?
Orçamento varia muito, mas aqui está um guia aproximado: um redesign de site mid-market com migração apropriada de SEO tipicamente custa $50,000-$200,000 para a build inicial. Sites enterprise podem exceder $500,000. O trabalho de migração de SEO especificamente (auditing, mapeamento de redirect, QA, monitoramento) adiciona aproximadamente 15-25% ao custo total do projeto. Esse é dinheiro bem gasto quando você considera a receita em risco.
Qual é o maior risco em um website redesign de uma perspectiva de SEO?
Redirecionamentos quebrados ou faltando. Full stop. Cada outro problema de SEO -- meta tags faltando, estruturas de heading mudadas, page speed mais lenta -- pode ser corrigido pós-lançamento com impacto gerenciável. Mas se Google rastreia milhares de páginas 404 porque redirecionamentos não estavam em lugar, o dano se compõe rapidamente e recuperação é lenta.
Devemos congelar mudanças de conteúdo durante a migração?
Sim, implemente um conteúdo freeze 2-3 semanas antes do lançamento. Qualquer conteúdo novo publicado durante essa janela precisa ser manualmente adicionado a ambos sites antigo e novo, o que cria trabalho extra e espaço para erro. Planeje seu calendário editorial ao redor da timeline de migração.
Como monitoramos saúde de SEO após lançamento?
Configure monitoramento diário para os primeiros 30 dias. No mínimo, rastreie: relatório de cobertura de índice do Google Search Console (veja picos em páginas "Excluídas"), estatísticas de crawl (taxa de crawl deve aumentar pós-lançamento conforme Google descobre mudanças), tráfego orgânico vs. baseline (compare mesmo dia-da-semana, não dias sequenciais) e posições de ranking para seus top 50-100 keywords. Ferramentas como ContentKing ou Lumar podem automatizar monitoramento em tempo real.
Podemos mudar nosso nome de domínio durante um redesign?
Você pode, mas entenda que é o cenário de migração de risco mais alto. Uma mudança de domínio mais um redesign significa Google tem que processar dois sinais principais simultaneamente. Se possível, separe os dois: redesenhe no domínio existente primeiro, estabilize por 3-6 meses, então migre para o novo domínio. Se você deve fazer ambos ao mesmo tempo, adicione pelo menos 4-6 semanas adicionais à timeline para QA extra e monitoramento.
Pronto para começar?
Se você tem um redesign no horizonte e não quer apostar com seu tráfego orgânico, obtenha uma proposta em 48 horas. Faremos uma revisão de seus requisitos e diremos exatamente como um redesign seguro de migração se parece para seu site.