O que é um site de migração?

Um site de migração é um termo amplamente utilizado por profissionais de SEO para descrever qualquer evento no qual um site passa por mudanças substanciais em áreas que possam afetar significativamente a visibilidade nos motores de pesquisa — normalmente as alterações para o site do local, plataforma, estrutura, conteúdo, design, UX.

Google documentação on-site migrações não cubra-os com grande profundidade e despreza o fato de que, muitas vezes, resultam em tráfego significativo e perda de receita, o que pode durar de algumas semanas a vários meses, dependendo da extensão da classificação do mecanismo de pesquisa de sinais de ter sido afetado, bem como o tempo pode ser afetado de negócio para implantação de um plano de recuperação com êxito.

Links de acesso rápido

Site lista de verificação de migração (8 páginas em PDF)migração do Site examplesSite migração typesCommon de migração do site pitfallsSite migração process1. Âmbito e planning2. Pré-lançamento preparation3. Pré-lançamento testing4. O dia do lançamento actions5. Pós-lançamento testing6. Desempenho reviewAppendix: ferramentas Úteis

Site exemplos de migração

A seção a seguir descreve como o bem-sucedidas e malsucedidas site migrações olhar e explica por que é 100% possível sair de uma migração do site, sem sofrer perdas significativas.

Desmascarando o “tráfego esperado soltar” mito

Qualquer pessoa que tenha estado envolvido com um site de migração provavelmente já ouviu falar da teoria generalizada de que resulte de facto tráfego e de perda de receitas. Mesmo que esta afirmação contém alguma verdade para alguns casos muito específicos (por exemplo, movendo-se a partir de uma estabelecido de domínio para um novo) ele não deve ser tratado como evangelho. É inteiramente possível migrar sem perder qualquer tráfego ou receita, você ainda pode desfrutar de um crescimento significativo logo após o lançamento de um novo website. No entanto, isso só pode ser alcançado se cada passo tem sido bem planejado e executado.

Exemplos de êxito site migrações

O gráfico a seguir ilustra um grande retalhista do reino UNIDO da fracassada de migração do site de onde o site perdeu 35% de sua visibilidade duas semanas após a mudança de HTTP para HTTPS. Ele levou cerca de seis meses para se recuperar totalmente, o que deve ter tido um impacto significativo nas receitas de pesquisa orgânica. Este é um exemplo típico de um pobre de migração do site, possivelmente causado por falta de planejamento ou de execução.

Exemplo de um pobre de migração do site — recuperação levou 6 meses!

Mas a recuperação pode não ser sempre possível. Abaixo visibilidade gráfico de outro grande retalhista do reino UNIDO, onde o HTTP para HTTPS transição resultou em um permanente 20% visibilidade perda.

Outro exemplo de um pobre de migração do site — não há sinais de recuperação de 6 meses!

Na verdade, isso é totalmente possível migrar a partir de HTTP para HTTPS, sem perder muito tráfego de e para um período tão longo, além das primeiras semanas, onde há alta volatilidade, como o Google descobre as novas URLs e atualizações de resultados de pesquisa.

Exemplos de sucesso no site migrações

O que faz o sucesso de uma migração do site se parece? Isso depende muito do sítio tipo de migração, os objetivos e KPIs (mais detalhes mais tarde). Mas na maioria dos casos, o sucesso de um site de migração mostra pelo menos uma das seguintes características:

O mínimo de perda de visibilidade durante as primeiras semanas (meta de curto prazo)

A visibilidade de crescimento depois — dependendo do tipo de migração (objetivo de longo prazo)

O seguinte visibilidade relatório é retirado de HTTP para HTTPS migração do site, que também foi acompanhado por melhorias significativas para o site tempo de carregamento das páginas.

O seguinte visibilidade relatório é de um site completo de revisão, que eu tive a sorte de estar envolvido com vários meses de antecedência e suporte durante a estratégia, de planejamento e de testes de fases, que foram igualmente importantes.

Como normalmente ocorre no local, projetos de migração, a data de lançamento teve que ser empurrado para trás algumas vezes, devido aos riscos de lançamento de um novo site prematuramente e antes de grandes obstáculos técnicos foram totalmente resolvidos. Mas como você pode ver abaixo uma visibilidade gráfico, a espera valeu a pena. Orgânica visibilidade não só não cair (como a maioria normalmente seria de esperar) mas, na verdade, começou a crescer a partir da primeira semana.

A visibilidade de crescimento de um mês após a migração atingiu 60%, enquanto o tráfego orgânico de crescimento de dois meses pós-lançamento, superou os 80%.

Exemplo de um muito bem-sucedido site de migração instantânea de crescimento, na sequência do novo site de lançamento!

Este foi um complexo de migração como o novo site foi re-projetado e construído a partir do zero em uma nova plataforma, com uma melhor site de taxonomia, que incluiu novas páginas de destino, uma actualização da estrutura de URL, muitos redireciona para preservar link de capital, além de uma troca de HTTP para HTTPS.

Em geral, a introdução de muitas mudanças ao mesmo tempo pode ser complicado, porque se algo der errado, você vai lutar para descobrir o que exatamente é a culpa. Mas, ao mesmo tempo, deixando grandes mudanças para um momento posterior não é ideal, pois ela requer mais recursos. Se você souber o que está fazendo, fazendo várias mudanças positivas de uma só vez pode ser muito rentável.

Antes de entrar no âmago da questão de como você pode transformar um site mais complexo projeto de migração em um sucesso, é importante executar através do site principal tipos de migração, bem como explicar os principais motivos de tantas site migrações falhar.

Tipos de migração do Site

Existem muitos tipos de migração do site. Tudo depende da natureza das alterações que acontecem.

Google documentação principalmente cobre migrações com o site alterações de localização, que são categorizados da seguinte maneira:

• Site move com as mudanças de URL
• Site move-se sem alterações de URL

Site migrações de movimentação

Estas geralmente ocorrem quando um site move-se para uma URL diferente devido a qualquer um dos abaixo:

Alteração no protocolo de

Um exemplo clássico é quando a migração a partir de HTTP para HTTPS.

Subdomínio ou subpasta alterar

Muito comum em SEO internacional em que uma empresa decide mover um ou mais ccTLDs em subdomínios ou subpastas. Outro exemplo comum é quando um site móvel que fica em um subdomínio separado ou subpasta torna-se ágil e desktop e mobile URLs são uniformizados.

Alteração de nome de domínio

Ocorre normalmente quando uma empresa é de marca e deve mover-se de um domínio para outro.

Domínio de nível superior de alteração

Isso é comum quando uma empresa decide lançar sites internacionais e precisa mover-se de um ccTLD (country code top-level domain) para um gTLD (generic top-level domain) ou vice-versa, por exemplo, movendo-se a partir .co.reino unido .com, ou movendo-se a partir .com .co.reino unido e assim por diante.

A estrutura do Site alterações

Essas mudanças são para a arquitetura do site, que geralmente afetam as internas do site a ligação e estrutura de URL.

Outros tipos de migrações

Existem outros tipos de migração, que são acionados pelas alterações ao conteúdo do site, a estrutura, o design, ou plataforma.

Replatforming

Este é o caso quando um site é movido a partir de uma plataforma de CMS para outro, por exemplo, migrar do WordPress para Magento ou apenas a atualização para a última versão da plataforma. Replatforming pode, em alguns casos, resultar também em design e as mudanças de URL devido a limitações técnicas que, muitas vezes, ocorre quando a mudança de plataformas. É por isso que re-plataformas migrações raramente resultar em um site que parece ser exatamente o mesmo que o anterior.

Migrações de conteúdo

Principais content alterações, tais como conteúdo reescreve, conteúdo de consolidação, ou o conteúdo de poda pode ter um grande impacto em um site de busca orgânica visibilidade, dependendo da escala. Estas alterações muitas vezes pode afetar o site da taxonomia, a navegação e links internos.

Móveis de alterações de configuração

Com tantas opções disponíveis para um site móvel do programa de configuração mover, permitindo a aplicação de indexação, a construção de um AMP site, ou a construção de um site do PWA também pode ser considerado como parcial site migrações, especialmente quando existente um site para dispositivos móveis está a ser substituído por um aplicativo, AMP, ou PWA.

Mudanças estruturais

Estes são muitas vezes causados por grandes mudanças para o site da taxonomia que têm impacto sobre a navegação no site, links internos de usuário e viagens.

Site redesenha

Estes podem variar de design principais alterações na aparência de uma página web completa renovação que também pode incluir significativo de mídia, código e copie as alterações.

Híbrido migrações

Além do mencionado acima, existem vários híbridos tipos de migração que podem ser combinados em praticamente qualquer maneira possível. O mais alterações do que apresentar-se, ao mesmo tempo, maior será a complexidade e os riscos. Apesar de fazer muitas mudanças ao mesmo tempo, aumenta os riscos de algo dar errado, pode ser mais custo-efetiva a partir de uma perspectiva de recursos, se a migração é muito bem planejado e executado.

Comum de migração do site armadilhas

Apesar de todos os migração do site é diferente, há alguns temas comuns para trás o mais típico site de migração de desastres, com a maior a ser o seguinte:

Estratégia pobre

Alguns sites de migrações estão fadadas ao fracasso caminho antes que o novo site é lançado. Uma estratégia que é construído em cima de claro e realista objectivos é muito menos provável de trazer sucesso.

O estabelecimento de objetivos mensuráveis, é essencial para medir o impacto da migração pós-lançamento. Para a maioria site migrações, o principal objetivo deve ser o de retenção do site do tráfego actual e os níveis de rendimento. Em alguns casos, a barra pode ser levantada superior, mas, em geral, antecipação ou previsão de crescimento deverá ser um objectivo secundário. Isto irá ajudar a evitar a criação de expectativas irreais.

Falta de planejamento

Chegando com um detalhado plano de projeto o mais cedo possível, irá ajudar a evitar atrasos ao longo do caminho. Fator adicional de tempo e recursos para lidar com os imprevistos que podem surgir. Não importa o quão bem pensado e detalhado o plano, é altamente improvável que tudo vai sair como o esperado. Seja flexível com o seu plano e aceitar o fato de que há quase certamente será atrasos. Mapear todas as dependências e fazer todos os participantes cientes deles.

Evitar a planear lançar o site perto de seu pico sazonal, porque se algo der errado, você não terá tempo suficiente para corrigir os problemas. Por exemplo, os varejistas devem evitar o lançamento de um site de fechar a setembro/outubro) para evitar colocar o ocupado pré-Natal, período em risco. Neste caso, seria muito mais sábio do lançamento durante o mais silencioso meses de verão.

A falta de recursos

Antes de cometer a um site de um projeto de migração, estimar o tempo e o esforço necessários para torná-lo um sucesso. Se o seu orçamento é limitado, fazer uma chamada para saber se vale a pena ir em frente com uma migração que é provável que falhar em cumprir os seus objectivos estabelecidos e causar perda de receitas.

Como regra geral, tente incluir um buffer de pelo menos 20% de adicional de recursos que, inicialmente, você acha que o projeto vai exigir. Este buffer adicional mais tarde irá permitir que você a rapidamente resolver quaisquer questões assim que elas surgirem, sem comprometer o sucesso. Se os seus recursos estão muito apertadas ou você começar a cortar os cantos, nesta fase inicial, o site de migração estará em risco.

Falta de SEO, UX/consulta

Quando as mudanças estão ocorrendo em um site, cada decisão deve ser ponderada, a partir de uma UX e SEO ponto de vista. Por exemplo, a remoção de grandes quantidades de conteúdo ou links para melhorar a UX podem danificar o site da capacidade de destino de negócios críticos, palavras-chave ou resultado no rastreamento e indexação de assuntos. Em ambos os casos, tais alterações podem danificar o site de busca orgânica visibilidade. Por outro lado, tendo muita cópia de texto e algumas imagens podem ter um impacto negativo sobre o envolvimento dos usuários e danos do site conversões.

Para evitar riscos, nomear experientes SEO e UX consultores para que eles possam discutir as potenciais consequências de cada alteração com chave de negócios interessados que entender o negócio meandros melhor do que ninguém. Os prós e contras de cada opção deverá ser avaliado antes de tomar qualquer decisão.

Final de envolvimento

Site migrações podem se estender por vários meses, requerem planejamento e tempo suficiente para os testes. Busca de profissional de suporte da tarde, é muito arriscado, porque passos cruciais podem ter sido perdidas.

A ausência de testes

Além de uma grande estratégia e pensativo plano, dedicar algum tempo e esforço para testes rigorosos antes de lançar o site. É muito mais preferível adiar o lançamento se o teste identificou problemas críticos em vez de apressar-se um esboço de implementação em produção. Escusado será dizer que você não deve iniciar um site, se ele ainda não foi testado por ambos os peritos de SEO e equipes de UX.

A atenção aos detalhes também é muito importante. Certifique-se de que os desenvolvedores estão plenamente conscientes dos riscos associados com má implementação. Educar os desenvolvedores sobre o impacto direto de seus trabalhos sobre o tráfego de um site (e, portanto, da receita) pode fazer uma grande diferença.

Resposta lenta à resolução de bug

Sempre haverá bugs para corrigir uma vez que o novo site vai viver. No entanto, alguns erros são mais importantes do que outros, e precisam de atenção imediata. Por exemplo, o lançamento de um novo site só para descobrir que o motor de pesquisa aranhas ter dificuldade em rastrear e indexar o conteúdo do site exigir imediata correção. Uma resposta lenta aos principais obstáculos técnicos, às vezes, pode ser catastrófico e levar um longo tempo para se recuperar.

Subestimando escala

As empresas interessadas, muitas vezes, não antecipar site migrações para ser tão demorada e mais pesados. Não é incomum para os altos partes interessadas para a procura que o novo site lançado no planejado para o dia, independentemente de estar 100% pronto ou não. O lema “vamos lançar o mais rápido possível e corrigir mais tarde” é um erro clássico. O que a maioria das pessoas desconhece é que ele pode levar apenas alguns dias para busca orgânica visibilidade para o tanque, mas a recuperação pode demorar vários meses.

É da responsabilidade do consultor e gerente de projeto para educar clientes, executá-los através de todas as diferentes fases e cenários, e explique o que cada um comporta. As empresas interessadas, em seguida, são capazes de tomar decisões mais informadas e suas expectativas devem ser mais fáceis de gerenciar.

Site do processo de migração

O site do processo de migração pode ser dividida em seis fases essenciais. Todos eles são igualmente importantes e ignorar qualquer um dos abaixo tarefas podem dificultar a migração do sucesso a vários níveis.

Fase 1: Escopo E Planejamento

Trabalhar fora do escopo do projeto

Independentemente das razões por trás de um site de um projeto de migração, você precisa estar cristalina sobre os objetivos direito desde o início, porque estes irão ajudar a definir e gerenciar as expectativas. Mover um site de HTTP para HTTPS é muito diferente de passar por uma reformulação completa do site, portanto, os dois devem ter objectivos diferentes. Em primeira instância, o objetivo deve ser manter o site níveis de tráfego, enquanto que, no segundo você poderia apontar para o crescimento.

Um site de migração é um grande opportunity para o endereço legado problemas. Inclusive muitos desses medida do possível, no escopo do projeto deve ser muito rentável, porque a responder a estas questões pós-lançamento vai exigir muito mais recursos.

No entanto, em cada caso, identificar os aspectos mais críticos para o projeto ser bem-sucedido. Identificar todos os riscos que possam ter um impacto negativo sobre o site visibilidade e considerar quais as precauções a tomar. Idealmente, preparar alguns de previsão de cenários de acordo com os diferentes riscos e oportunidades de crescimento. Escusado será dizer que a previsão de cenários devem ser preparados por experientes migração do site consultores.

Incluir o maior número de interessados possível nesta fase inicial irá ajudá-lo a adquirir uma compreensão mais profunda dos maiores desafios e oportunidades em todas as divisões. Pedir feedback do seu conteúdo, SEO, UX e análise de equipes e montar uma lista com os principais problemas e oportunidades. Em seguida, você precisa descobrir o que é o ROI potencial de abordar cada um desses seria. Finalmente, escolha uma das opções disponíveis com base em seus objetivos e recursos disponíveis, que vão formar o site a estratégia de migração.

Agora você deve ser deixado com uma lista de prioridades de atividades que deverão ter um ROI positivo, se implementado. Estes, em seguida, deve ser comunicada e discutida com todos os stakeholders, de modo a definir objectivos realistas, concordar com o projeto, escopo e definir as expectativas certas desde o início.

Preparar o plano de projeto

O planejamento é importante porque o site migrações, muitas vezes, ser muito complexos projetos que pode facilmente se estender por vários meses. Durante a fase de planejamento, cada tarefa necessita de um proprietário (i.e. consultor de SEO, UX consultor, editor de conteúdo, web developer) e uma previsão de data de entrega. Qualquer dependências devem ser identificados e incluídos no plano de projeto, para que todos fiquem cientes de quaisquer actividades que não pode ser cumprido, devido a estar dependente dos outros. Por exemplo, os redirecionamentos não pode ser testada, a menos que o redirecionamento de mapeamento foi concluída e o redireciona foram implementadas na encenação.

O plano de projeto deve ser compartilhado com todos os envolvidos, tão cedo quanto possível, de modo que há tempo suficiente para discussões e esclarecimentos. Cada atividade deve ser descrita em detalhes, para que as partes interessadas estão cientes de que cada tarefa implicaria. Escusado será dizer que impecável de gerenciamento de projeto é necessário para organizar e realizar as atividades necessárias de acordo com a programação.

Uma parte crucial do plano de projeto está recebendo a esperada data de lançamento para a direita. Idealmente, o novo site deverá ser lançado durante um tempo quando o tráfego é baixo. Novamente, evitar o lançamento antes de ou durante um período de pico, porque as consequências poderiam ser devastadoras se as coisas não saem como o esperado. Uma coisa para ter em mente é que como o site migrações nunca vá totalmente para o plano, um certo grau de flexibilidade vai ser necessário.

Fase 2: preparação de Pré-lançamento

Estes incluem quaisquer atividades que precisam ser realizadas enquanto o novo site ainda está em desenvolvimento. Por este ponto, o novo site de SEO de requisitos deve ter sido capturada já. Você deve ser o contacto com os designers e arquitetos de informação, fornecendo feedback sobre protótipos e wireframes bem antes de o novo site torna-se disponível em um ambiente de teste.

Wireframes revisão

Revisão do novo site protótipos ou wireframes antes desenvolvimento se inicia. A revisão do novo site principal de modelos pode ajudar a identificar tanto de SEO e UX problemas numa fase precoce. Por exemplo, você pode descobrir que grande parte do conteúdo foi removido de páginas da categoria, que deve ser imediatamente sinalizado. Ou você pode descobrir que alguns de alto tráfego-condução páginas não aparecem na janela de navegação principal. Qualquer mudança radical no projeto ou copiar as páginas devem ser cuidadosamente analisados para o potencial questões SEO.

Preparar as técnicas de SEO especificações

Uma vez que os protótipos e wireframes foram revistos, preparar um detalhado de técnicas de SEO especificação. O objetivo deste importante documento é capturar todos os elementos essenciais de SEO requisitos os desenvolvedores precisam estar cientes antes de trabalhar o escopo do projeto em termos de trabalho e de custos. É durante esta fase que os orçamentos são assinados; se o seu SEO requisitos não estão incluídos, pode ser impossível incluí-los mais tarde para baixo da linha.

As técnicas de SEO especificação precisa ser muito detalhado, mas escrito de tal forma que os desenvolvedores podem facilmente transformar os requisitos em ações. Este não é um documento para explicar por que algo precisa ser implementado, mas como ele deve ser implementado.

Certifique-se de incluir exigências específicas que abrangem, no mínimo, as seguintes áreas:

• Estrutura de URL
• Meta dados (incluindo gerado dinamicamente valores padrão)
• Dados estruturados
• Paramentos e meta robots directivas
• Copie e títulos
• Principal e secundário de navegação
• Os links internos (em qualquer forma)
• Paginação
• XML sitemap(s)
• Sitemap HTML
• Hreflang (se houver internacional sites)
• Móveis de instalação (incluindo o aplicativo, AMP, ou do site do PWA)
• Redirecionamentos
• Página 404 personalizada
• Código JavaScript, CSS, e arquivos de imagem
• Tempo de carregamento das páginas (para desktop e celular)

A especificação deve incluir também as áreas do CMS funcionalidade que permite que os usuários:

• Especificar URLs personalizadas e padrão de substituição queridos
• Atualização de títulos de página
• Atualização de descrições de meta
• Atualização de qualquer h1–h6 títulos
• Adicionar ou alterar o padrão de tag canônica
• Definir a meta de robôs de atributos para index/noindex/follow/nofollow
• Adicionar ou editar o texto do atributo alt de cada imagem
• Incluem Open Graph campos para a descrição, URL, imagem, tipo, sitename
• Incluir Twitter Open Graph campos para cartão, URL, título, descrição, imagem
• Upload em massa ou alterar redirecionamentos
• Atualizar o robots.txt arquivo

Também é importante certificar-se de que, ao atualizar um atributo específico (e.g. um h1), outros elementos não são afetados (por exemplo, o título da página ou qualquer menus de navegação).

A identificação de prioridade páginas

Um dos maiores desafios com o site migrações é que o sucesso dependerá, em grande medida, a qualidade e a quantidade de páginas que foram migrados. Portanto, é muito importante certificar-se de que você se concentrar nas páginas que realmente importa. Estas são as páginas que têm vindo a impulsionar o tráfego para o legado do site, as páginas que foram vencidos, links, páginas que convertem bem, etc.

Para fazer isso, você precisa:

Rastrear o legado do site

Identificar todas as páginas indexáveis

Identificar melhor desempenho páginas

Como rastrear o legado do site

Rastrear o antigo site para que você tenha uma cópia de todas as URLs, títulos de página, meta dados, cabeçalhos, redirecionamentos, links quebrados, etc. Independentemente do rastreador aplicativo de escolha (ver Anexo), certifique-se de que o rastreamento não é muito restritiva. Preste atenção para o rastreador de configurações antes de rastrear o legado site e considerar se você deve:

• Ignorar robots.txt (em caso de qualquer uma das partes vitais são acidentalmente bloqueado)
• Siga interno “nofollow” links (para que o rastreador atinge mais páginas)
• O rastreamento de todos os subdomínios (dependendo do escopo)
• Rastreamento de fora pasta de início (dependendo do escopo)
• Mudar o user agent Googlebot (área de trabalho)
• Mudar o user agent Googlebot (smartphone)

Pro dica: Mantenha uma cópia do antigo site de rastreamento de dados (em um arquivo ou na nuvem) por vários meses depois que a migração foi concluída, apenas no caso de você precisar de qualquer dos antigos dados do site uma vez que o novo site tem ido ao vivo.

Como identificar as páginas indexáveis

Uma vez que a pesquisa estiver concluída, o trabalho em identificar o legado do site de páginas indexadas. Estas são quaisquer páginas HTML com as seguintes características:

• Retorno a 200 r serveresposto
• Não tem uma tag canônica ou têm uma auto-referência URL canônica
• Não tem uma meta robots noindex
• Não estão excluídos da robots.txt arquivo
• Internamente são ligados a partir de outras páginas (de não-órfãos páginas)

A essas páginas são apenas páginas que têm o potencial para gerar tráfego para o site e, portanto, precisa ser priorizada para fins de sua migração do site. Estas são as páginas que vale a pena otimizar (se é que vai existir no novo site) ou redirecionando o (se não existir no novo site).

Como identificar o melhor desempenho de páginas

Depois de identificadas todas as páginas indexáveis, poderá ter de realizar mais trabalho, especialmente se o legado site consiste em um grande número de páginas e otimizar ou redirecionando todos eles é impossível devido a falta de tempo, de recursos, ou restrições técnicas.

Se este for o caso, você deve identificar o legado do site de desempenho superior páginas. Isso vai ajudar com a priorização das páginas para se concentrar durante as fases posteriores.

Recomenda-se preparar uma folha de cálculo que inclui os campos abaixo:

• Legado URL (inclui apenas o intercambiáveis, do craw de dados)
• Orgânica visitas durante os últimos 12 meses (google Analytics)
• Receitas, conversões, e a taxa de conversão durante os últimos 12 meses (google Analytics)
• Visualizações de página nos últimos 12 meses (google Analytics)
• Número de cliques a partir dos últimos 90 dias (Pesquisa de Console)
• Superior páginas (Majestic SEO/Ahrefs)

Com as informações acima em um só lugar, agora é muito mais fácil de identificar suas páginas mais importantes: aqueles que geram orgânica visitas, converter bem, contribuem para a receita, tem um bom número de domínios de referência vinculá-los, etc. Estas são as páginas que você deve se concentrar para o sucesso de uma migração do site.

Desempenho superior páginas, idealmente, deveria também existir no novo site. Se, por qualquer razão, eles não, eles devem ser redirecionado para a página mais relevante para que os usuários solicitando-lhes que não pousar em 404 páginas e o link de capital anteriormente tinham permanece no site. Se qualquer uma dessas páginas deixam de existir e não são devidamente redirecionado, o seu site de rankings e tráfego vai ser negativamente afetados.

Benchmarking

Uma vez que o lançamento do novo site está chegando perto, você deve referência o legado desempenho do site. O Benchmarking é essencial, não só para comparar o novo site do desempenho com a anterior, mas também para ajudar a diagnosticar quais áreas um desempenho inferior no novo site e resolver rapidamente-los.

Palavras-chave ranking de rastreamento

Se você não acompanhar o site de rankings com freqüência, você deve fazê-lo apenas antes de o novo site entrar no ar. Caso contrário, você será mais tarde luta para descobrir se a migração tem corrido bem ou exatamente onde as coisas deram errado. Não deixe isso para o último minuto no caso de algo der errado — com uma semana de antecedência seria o momento ideal.

Passar algum tempo nos quais as palavras-chave são mais representativos do site de busca orgânica visibilidade e acompanhá-los em computadores e dispositivos móveis. Porque monitoramento de milhares de cabeça, médio e longo rabo-de-combinações de palavra-chave é geralmente irrealistas, o mínimo que você deve monitorar são palavras-chave que geram tráfego para o site (palavras-chave de classificação na página) e decentes volume de pesquisa (cabeça/meados de cauda foco)

Se você começar o tráfego de marca e sem marca de palavras-chave, você também deve decidir que tipo de palavras-chave para concentrar-se em mais de um controle de ângulo de visão. Em geral, não marca as palavras-chave tendem a ser mais competitivo e volátil. Para a maioria dos sites não faria sentido se concentrar principalmente sobre estes.

Não se esqueça de acompanhar rankings em computadores e dispositivos móveis. Isto irá torná-lo muito mais fácil para diagnosticar problemas de pós-lançamento, deverá haver problemas de desempenho em um tipo de dispositivo. Se você receber um alto volume de tráfego de mais de um país, considerar a classificação de acompanhamento de palavras-chave em outros mercados, também, porque a visibilidade e ranking pode variar significativamente de país para país.

O desempenho do Site

O novo site tempo de carregamento das páginas pode ter um grande impacto sobre o tráfego e vendas. Vários estudos têm mostrado que quanto mais tempo uma página demora a carregar, maior a taxa de rejeição. A menos que o site antigo tempo de carregamento das páginas e do site pontuações de desempenho têm sido registradas, vai ser muito difícil atribuir qualquer tráfego ou perda de receita para o site a questões relacionadas com o desempenho uma vez que o novo site tem ido ao vivo.

É recomendado que você reveja todos os principais tipos de página usando o Google PageSpeed Insights e Farol de ferramentas. Você pode usar tabelas de resumo, como mostrado abaixo, para benchmark de alguns dos mais importantes métricas de desempenho, que será útil para comparações, uma vez que o novo site vai viver.

MÓVEIS

Velocidade

FCP

DCL

Otimização

Otimização de pontuação

Página inicial

Rápido

0,7 s

1.4 s

Bom

81/100

Página da categoria

Lenta

1.8 s

5.1 s

Médio

78/100

Subcategoria página

Média

0,9 s

2.4 s

Médio

69/100

Página do produto

Lenta

1.9 s

5.5 s

Bom

83/100

Ambiente de TRABALHO

Velocidade

FCP

DCL

Otimização

Otimização de pontuação

Página inicial

Bom

0,7 s

1.4 s

Média

81/100

Página da categoria

Rápido

0,6 s

1.2 s

Médio

78/100

Subcategoria página

Rápido

0,6 s

1.3 s

Médio

78/100

Página do produto

Bom

0,8 s

1.3 s

Bom

83/100

Antigo site de rastreamento de dados

Poucos dias antes de o novo site substitui o antigo, execute um final de rastreamento do site antigo. Isso poderia mais tarde ser inestimável, em caso de problemas de optimização no novo site. Um final de rastreamento irá permitir que você salve as informações vitais sobre o site antigo títulos de página, meta descrições, h1–h6 títulos, status do servidor, tag canonical, noindex/nofollow páginas, inlinks/saída, nível, etc. Tendo todas essas informações disponíveis poderia poupar-lhe um monte de problemas se, por exemplo, o novo site não estiver bem otimizado ou sofre de técnicas de problemas de configuração incorreta. Tente também para salvar uma cópia do site antigo robots.txt e XML sitemaps no caso de você precisar de mais tarde.

Pesquisa Console de dados

Também considerar a exportação como muito do antigo site de Pesquisa do Console de dados possível. Estes só estão disponíveis por 90 dias, e as chances são de que, uma vez que o novo site entrar no ar o site antigo Pesquisa Console de dados desaparecerá, mais cedo ou mais tarde. Dados pena de exportação inclui:

• Análise de pesquisa de consultas & páginas
• Erros de rastreamento
• Bloqueado recursos
• Móveis problemas de usabilidade
• Parâmetros de URL
• Dados estruturados erros
• Links para o seu site
• Ligações internas
• Status do índice

Redirecionamentos de preparação

Os redirecionamentos de implementação é uma das mais importantes atividades durante uma migração do site. Se o legado do site URLs deixam de existir e não estão corretamente redirecionado, o site do ranking e visibilidade simplesmente tanque.

Por que redireciona importante no site migrações?

Redirecionamentos são extremamente importantes, porque ajudam os mecanismos de pesquisa e usuários a encontrar páginas que podem não existir mais, ter sido renomeada ou movida para outro local. A partir de um SEO ponto de vista, redireciona ajudar os motores de busca descobrir e indexar um site novo URLs mais rápido, mas também entender como o velho páginas do site estão associados com as novas páginas do site. Esta associação permitirá a classificação de sinais para passar de páginas antigas para as novas, assim, as classificações são mantidas sem ser afetado negativamente.

O que acontece quando redirecionamentos não são corretamente implementadas?

Quando os redirecionamentos são mal implementadas, as consequências podem ser catastróficas. Utilizadores irá pousar em Não Encontrada páginas (os 404) ou irrelevante páginas que não cumprem a intenção do usuário. Em qualquer caso, o site de rejeição e taxas de conversão serão afetados negativamente. As consequências para os mecanismos de pesquisa podem ser igualmente catastrófica: eles vão conseguir associar o velho páginas do site com aqueles no novo site se o url não são idênticos. Classificação de sinais não passar do velho para o novo site, que irá resultar no ranking de quedas e de busca orgânica visibilidade perda. Além disso, ele terá motores de busca mais tempo para descobrir e indexar novas páginas do site.

301, 302, JavaScript redirecionamentos, ou meta refresh?

Quando os URLs entre a antiga e a nova versão do site são diferentes, use 301 (permanente) redirecionamentos. Esses dirá motores de busca para indexar as novas URLs, bem como encaminhar qualquer classificação de sinais de URLs antigos para os novos. Portanto, você deve usar redirecionamentos 301 se o seu site se move para/a partir de outro domínio/subdomínio, se você mudar a partir de HTTP para HTTPS, ou se o site ou partes dele foram reestruturados. Apesar de alguns de Google afirma que redirecionamentos 302 passar PageRank indexação do novo URLs seria mais lento e classificação de sinais pode demorar muito mais para ser passado da antiga para a nova página.

302 (temporário) redireciona só deve ser usado em situações onde um redirecionamento não precisa viver permanentemente e, portanto, a indexação a nova URL não é uma prioridade. Com redirecionamentos 302, motores de busca, inicialmente, ser relutantes para indexar o conteúdo do redirecionamento de URL de destino e passar em qualquer ranking de sinais para ele. No entanto, se os redirecionamentos temporários permanecem por um longo período do tempo sem ser removido ou atualizado, que pode acabar se comportando da mesma forma permanente (301) redirecionamentos. Use redirecionamentos 302 quando um redirecionamento é provável que precisam de atualização ou remoção, em um futuro próximo, bem como para qualquer país, de idioma, ou de dispositivo específicos redirecionamentos.

Meta refresh e JavaScript redirecionamentos devem ser evitados. Mesmo que o Google está ficando melhor e melhor em rastreamento de JavaScript, não há garantias de que estas irão ser descoberto ou passar ranking de sinais para as novas páginas.

Se você quiser saber mais sobre como o Google lida com os diferentes tipos de redirecionamentos, por favor, consulte John Mueller post.

Redirecionar processo de mapeamento

Se você tiver sorte o suficiente para trabalhar em uma migração que não envolvem alterações de URL, você pode ignorar esta seção. Caso contrário, leia mais para descobrir por qualquer legado páginas que não estar disponíveis no mesmo URL após a migração deve ser redirecionado.

A redirecionar o arquivo de mapeamento é uma folha de cálculo, que inclui as duas colunas a seguir:

• Legado URL do site –> URL uma página no site antigo.
• Novo URL do site –> URL uma página sobre o novo site.

Quando o mapeamento (redirecionar) uma página do antigo para o novo site, sempre tentar mapeá-la para mais relevantes página correspondente. Nos casos em que uma página em questão não existe, evitar o redirecionamento de página para a página inicial. Em primeiro lugar, redirecionar os usuários para páginas irrelevantes resulta em uma má experiência do usuário. O Google afirmou que redirecionamentos de páginas “em massa” para irrelevantes páginas serão tratadas como erros soft 404 e devido a este não ser passar todas SEO valor. Se você não pode encontrar uma página equivalente no novo site, tentar mapeá-la para seu pai a página da categoria.

Uma vez que o mapeamento é concluída, o arquivo terá que ser enviado para a equipe de desenvolvimento para criar os redirecionamentos, para que estes possam ser testados antes de lançar o novo site. A implementação de redirecionamentos é uma outra parte do site ciclo de migração, onde as coisas podem dar errado.

Aumentando a eficiência durante o redirecionamento de mapeamento de processo

Redirecionar mapeamento requer uma grande atenção ao detalhe e precisa ser realizado por experientes SEOs. O mapeamento de URL em sites pequenos poderiam, em teoria, ser feito manualmente, o mapeamento de cada URL do legado site para uma URL no novo site. Mas em sites grandes que consistem em milhares ou mesmo centenas de milhares de páginas, mapear manualmente cada URL é praticamente impossível e automação precisa ser introduzida. Depender de certos atributos comuns entre o legado e o novo site pode ser uma enorme economia de tempo. Tais atributos podem incluir os títulos de página, títulos H1, ou outras única página identificadores, tais como os códigos de produto, SKUs, etc. Certifique-se de que os atributos que dependem para o redirecionamento de mapeamento são únicas e não são repetidos em várias páginas; caso contrário, você vai acabar com mapeamento incorreto.

Dica profissional: certifique-se de que a estrutura de URL do novo site é 100% finalizado em preparo antes de começar a trabalhar no redirecionamento de mapeamento. Não há nada mais arriscado do que o mapeamento de URLs que serão atualizados antes que o novo site vai viver. Quando os URLs são atualizados após o redirecionamento de mapeamento é concluída, você pode ter que lidar com situações indesejáveis após a inicialização, tais como redirecionamentos quebrados, redirecionar cadeias, e redirecionar loops. Um conteúdo a ser congelado deve ser colocado no site antigo com bastante antecedência da data de migração, de modo que existe um ponto de corte para o novo conteúdo a ser publicado no site antigo. Isto irá certificar-se de que nenhum páginas serão perdidas de redirecionamento de mapeamento e garantir que todas as páginas no antigo site redirecionado.

Não se esqueça de que o legado de redirecionamentos!

Você deve pegar o site antigo existente redireciona para garantir que eles sejam considerados quando da elaboração do redirecionamento de mapeamento para o novo site. A menos que você fizer isso, é provável que a atual do site de redirecionamento de arquivo serão substituídos por um novo a data de lançamento. Se isso acontecer, todo o legado redireciona que já estiveram no lugar deixará de existir e o site pode perder uma quantidade decente de link de capital, na medida em que dependerá em grande medida do site do volume de legado redirecionamentos. Por exemplo, um site que tem sofrido algumas migrações no passado deve ter um bom número de legado redireciona no lugar que você não quer ficar perdido.

Idealmente, preservar, como muitos dos legado redireciona possível, certificando-se de que estes não irá causar quaisquer problemas quando combinado com o novo site redireciona. É altamente recomendado para eliminar qualquer possível redirecionar cadeias nesta fase inicial, o que pode ser feito facilmente, verificando se a mesma URL aparece tanto como um “Legado” URL ” e “Novo URL do site” no redirecionamento de mapeamento de folha de cálculo. Se este for o caso, você precisará atualizar o “Novo URL do site” de acordo.

Exemplo:

UM URL redireciona para a URL B (legado de redirecionamento)

URL B redireciona para a URL C (novo redirecionamento)

O que resulta na seguinte redirecionar cadeia:

URL –> URL B –> C URL

Para eliminar isso, alterar a existente legado de redirecionamento e criar uma nova, de modo que:

UM URL redireciona para a URL C (alterado legado de redirecionamento)

URL B redireciona para a URL C (novo redirecionamento)

Dica profissional: Seleção redirecionamento de mapeamento de folha de cálculo para redirecionar loops. Estas ocorrem quando o “Legado” URL ” é idêntico ao “novo URL do site.” Redirecionar ciclos precisam ser removidos porque eles são resultado infinitamente carregamento de páginas que são inacessíveis para os usuários e motores de busca. Redirecionar loops deve ser eliminada, porque eles são instantâneas tráfego, conversão e ranking de assassinos!

Implementar cobertor regras de redirecionamento para evitar o conteúdo duplicado

É altamente recomendado que tente trabalhar as regras de redirecionamento que cobrir o maior número de solicitações de URL como possível. A implementação de regras de redirecionamento em um servidor web é muito mais eficiente do que depender de inúmeras um-para-um redirecionamento. Se o seu redirecionamento documento de mapeamento consiste de um número muito grande de redirecionamentos que precisa ser implementado como um-para-um, regras de redirecionamento do site, o desempenho pode ser afetado negativamente. Em qualquer caso, verifique com a equipe de desenvolvimento o número máximo de redirecionamentos servidor web pode lidar sem problemas.

Em qualquer caso, existem algumas redirecionamento padrão de regras que devem ser tomadas para o avoid gerando problemas de conteúdo duplicado:

• URL caso: Todos os URLs que contêm caracteres de letras maiúsculas deve ser 301 redirecionado para todos os casos de menor URLs, por exemplo, https://www.website.com/Page/ deve ser redirecionar automaticamente para https://www.website.com/page/

• Anfitrião: Por exemplo, todos os não-www URLs devem ser 301 redirecionado para www equivalente, ou seja https://website.com/page/ deve ser redirecionado para https://www.website.com/page/

• Protocolo: Em um site seguro, pedidos de HTTP URLs devem ser redireccionado para o equivalente a URL HTTPS, por exemplo, http://www.website.com/page/ deve redirecionar automaticamente para https://www.website.com/page/

• Barra: Por exemplo, os URLs não contém uma barra invertida à direita deve redirecionar para uma versão com uma barra, por exemplo, http://www.website.com/page deve redirecionar para http://www.website.com/page/

Mesmo se alguns desses redirecionamento padrão existem regras sobre o legado do site, não suponha que eles necessariamente existir no novo site, a menos que esteja explicitamente solicitado.

Evite redirecionamentos internos

Tente atualizar o site de links internos para que eles não acionar redirecionamentos internos. Mesmo que os mecanismos de busca possam seguir redirecionamentos internos, estes não são recomendados porque podem adicionar latência adicional de tempo de carregamento das páginas e também poderia ter um impacto negativo no motor de busca o tempo de rastreamento.

Não se esqueça de seus arquivos de imagem

Se as imagens do site foram movidos para um novo local, o Google recomenda que redirecionando o velho URLs de imagem para a nova url de imagem para ajudar o Google a encontrar e indexar as novas imagens com mais rapidez. Se não é fácil para redirecionar todas as imagens, tem por objetivo redirecionar pelo menos, os URLs de imagem que tenham acumulado backlinks.

Fase 3: Pré-lançamento de teste de

Quanto mais cedo você pode começar a testar, melhor. Certas coisas precisam ser totalmente implementado para ser testado, mas outros não. Por exemplo, jornada de usuário pode ser identificado logo a partir de protótipos ou wireframes design. Conteúdos relacionados a problemas entre o velho e o novo site ou conteúdo de inconsistências (e.g. entre o desktop e mobile site) também poderiam ser identificados em uma fase inicial. Mas o mais técnico de veículo só deve ser testado, uma vez totalmente implantado — coisas como redirecionamentos, tag canonical, ou XML sitemaps. O anterior problemas identificados, o mais provável é que eles vão ser abordadas antes de lançar o novo site. A identificação de certos tipos de problemas em uma fase posterior, não é custo-efetivo, exigiria mais recursos, e causar atrasos significativos. Pobres de testes e não permitindo que o tempo necessário para testar completamente todos os blocos de construção que podem afetar SEO e UX desempenho pode ter consequências desastrosas, logo após o novo site tem ido ao vivo.

Certificando-se de motores de busca não pode acessar o teste/teste do site

Antes de fazer o novo site disponível em uma plataforma/ambiente de teste, tome algumas precauções que os motores de busca não indexá-lo. Existem algumas maneiras diferentes de fazer isso, cada um com diferentes prós e contras.

Site disponível para IPs específicos (mais recomendado)

Fazendo o teste de site disponíveis somente para determinados (lista branca) de endereços IP é uma maneira muito eficaz para impedir que os motores de busca indexe. Qualquer pessoa que tentar acessar o site de teste a URL não ser capaz de ver qualquer conteúdo, a menos que seu IP foi adicionado à lista de permissões. A principal vantagem é que na lista de permissões que os usuários pudessem ter fácil acesso e rastrear o site sem quaisquer problemas. A única desvantagem é que, de terceiros ferramentas baseadas na web (tais como as ferramentas da Google) não podem ser utilizados devido a restrições de IP.

Proteção de senha

A senha de proteção de teste/teste de site é uma outra maneira de manter os rastreadores de mecanismo de pesquisa de distância, mas esta solução tem duas grandes desvantagens. Dependendo da aplicação, pode não ser possível para rastrear e testar protegida por senha do site, se o rastreador aplicativo não fazê-lo após a tela de login. A outra desvantagem: protegida por palavra-passe de web sites que utilizam formulários para a autenticação pode ser rastreado usando aplicativos de terceiros, mas há o risco de causar graves e inesperados problemas. Isso porque o rastreador de cliques em cada link em uma página (quando estiver conectado) e poderia facilmente acabar clicando em links que criar ou remover páginas, instalar/desinstalar plugins, etc.

Robots.txt bloqueio

Adicionando as seguintes linhas de código para o teste do site robots.txt arquivo irá impedir que mecanismos de busca rastreem o teste páginas do site.

User-agent: * Disallow: /

Uma desvantagem deste método é que, mesmo que o conteúdo que aparece no servidor de teste não são indexados, os URLs não permitidos podem aparecer em resultados de pesquisa do Google. Outra desvantagem é que, se o acima robots.txt arquivo move para o site ao vivo, ele irá causar graves de indexação de assuntos. Isso é algo que eu já tenha se deparado com inúmeras vezes, e por esta razão eu não recomendaria usar este método para bloquear motores de busca.

Jornada de usuário revisão

Se o site foi redesenhado ou reestruturadas, as chances são de que o usuário viagens serão afetados, em alguma medida. Revisão do usuário viagens o mais cedo possível, e bem antes de o novo site lança é difícil devido à falta de dados do usuário. No entanto, um experiente UX, o profissional será capaz de sinalizar quaisquer preocupações que possam ter um impacto negativo sobre o site da taxa de conversão. Porque o teste A/B nesta fase, quase nunca é possível, pode valer a pena a realização de alguns testes do usuário e tentar obter algum feedback de usuários reais. Infelizmente, problemas de experiência do usuário pode ser alguns dos mais difíceis para o endereço, pois eles podem exigir mega promoção alterações que ter um monte de tempo e esforço.

Em completo site de inspeções, nem todos os UX decisões podem sempre ser apoiado por dados e muitas decisões terão de ser baseadas nas melhores práticas, a experiência do passado, e o “gut feeling”, portanto, a obtenção de UX/CRO especialistas envolvidos o mais cedo possível pode pagar dividendos mais tarde.

Arquitetura do Site revisão

Um site de migração, muitas vezes é uma grande oportunidade para melhorar a arquitetura do site. Em outras palavras, você tem uma grande chance de reorganizar a sua palavra-chave alvo de conteúdo e maximizar o seu tráfego de pesquisa em potencial. A realização de ampla pesquisa de palavras-chave irá ajudar a identificar a melhor possível, categoria e subcategoria de páginas para que os usuários e motores de busca pode chegar a qualquer página no site, dentro de alguns cliques — o menos, o melhor, para que você não acabar com uma profunda taxonomia.

A identificação de novas palavras-chave com tráfego decente potencial e mapeamento-los em novas páginas de destino podem fazer uma grande diferença para o site do tráfego orgânico níveis. Por outro lado, melhorar a arquitetura do site precisa ser feito cuidadosamente. Itt pode causar problemas se, por exemplo, páginas importantes mover mais profundo para a nova arquitetura do site ou há muitos semelhantes páginas optimizadas para as mesmas palavras-chave. Alguns dos mais bem sucedidos site migrações são aqueles que alocar recursos significativos para melhorar a arquitetura do site.

Meta de dados e cópia de revisão

Certifique-se de que a página os títulos, meta descrições, títulos e cópia ter sido transferido do antigo para o novo site, sem problemas. Se você tiver criado quaisquer novas páginas, certifique-se de que estes são otimizados e não de palavras-alvo que já foi alvo de outras páginas. Se você está re-plataformas, estar ciente de que a nova plataforma pode ter diferentes valores padrão quando novas páginas são criadas. Lançamento do novo site corretamente, sem otimizado títulos de página ou qualquer tipo de falta de cópia terá um impacto negativo imediato no seu site de rankings e tráfego. Não se esqueça de verificar se qualquer conteúdo gerado pelo usuário (por exemplo, resenhas de usuários, comentários) também tem sido carregado.

Links internos de revisão

Links internos são a espinha dorsal de um website. Não importa o quão bem otimizado e estruturado o site da cópia, ela não será suficiente para o sucesso, a menos que ele é suportado por uma impecável, links internos de esquema. Ligações internas devem ser analisados durante todo o site, incluindo links encontrados em:

• Principal e secundário de navegação
• Cabeçalho e footer links
• Corpo links de conteúdo
• Links de paginação
• Ligações horizontais (artigos relacionados, produtos similares, etc.)
• Ligações verticais (e.g. a navegação de trilha)
• Cross-links de site (exemplo: links em sites internacionais)

As verificações técnicas

Uma série de técnicas as verificações devem ser realizadas para garantir que a nova técnica do site é de instalação de som e evitar vem entre as principais falhas técnicas após o novo site tem ido ao vivo.

Robots.txt arquivo revisão

Preparar o novo site robots.txt o ficheiro no ambiente de teste. Desta forma, você pode testá-lo por erros ou omissões e evitar enfrentando motor de busca rastrear problemas quando o novo site entrar no ar. Um erro clássico no site migrações é quando o robots.txt arquivo impede que o motor de pesquisa de acesso utilizando a seguinte diretiva:

Disallow: /

Se isso fica acidentalmente transportado para o site vivo (e muitas vezes acontece), ele vai impedir que os motores de busca de indexar o site. E quando os motores de busca não pode rastrear uma página indexada, as palavras-chave associadas com a página vai ficar rebaixado nos resultados da pesquisa e, eventualmente, a página vai ficar de janeiro-indexados.

Mas se o robots.txt arquivo de teste é preenchido com o novo site robots.txt directivas, este acidente poderia ser evitado.

Quando da elaboração do novo site robots.txt arquivo, certifique-se de que:

• Ele não bloqueia o acesso motor de busca para as páginas que são destinados para ser indexada.
• Ele não bloqueia qualquer JavaScript ou CSS recursos motores de busca exigem para compor o conteúdo da página.
• O legado do site robots.txt arquivo de conteúdo foi revisado e transportados, se necessário.
• Ele faz referência a um novo XML sitemaps(s), ao invés de incluir qualquer legado aqueles que não existem mais.

Tag Canonical revisão

Analise o site da canonical tags. Procure por páginas que não tem uma tag canônica ou ter uma canonical tag que está apontando para outro URL e pergunta se essa é a intenção. Não se esqueça de rastrear a tag canonical para saber se ele voltar a 200 resposta do servidor. Se não, você precisará atualizá-las para eliminar qualquer 3xx, 4xx ou 5xx respostas do servidor. Você também deve olhar para páginas que tenham a tag canônica apontando para outra URL combinado com um noindex directiva, porque esses dois são conflitantes sinais e você’ll precisa eliminar um deles.

Meta robots revisão

Uma vez que você tenha pesquisado o site de preparo, procure por páginas com a meta de robôs propriedades definidas para “noindex” ou “nofollow.” Se este for o caso, rever cada um deles para se certificar de que isso é intencional e remover o “noindex” ou “nofollow” directiva, se é não.

XML sitemaps revisão

Prepare-se dois tipos de sitemaps: que contém todo o novo site indexável páginas, e outro que inclui todo o site antigo intercambiáveis páginas. O primeiro vai ajudar a tornar o Google ciente do novo site indexável URLs. O último vai ajudar o Google a tornar-se ciente de que os redirecionamentos que estão em vigor, e o fato de que alguns de URLs indexadas mudaram-se para novos locais, para que ele possa descobri-los e atualização de resultados de pesquisa mais rápido.

Você deve verificar cada um XML sitemap para certificar-se de que:

• Ele valida sem problemas
• Ele é codificado como UTF-8
• Ele não contém mais de 50.000 linhas
• O seu tamanho não exceda 50MBs quando descompactado

Se houver mais de 50 mil linhas ou o tamanho do arquivo exceder a 50 MB, você deve quebrar o sitemap para baixo em menores. Isso impede que o servidor tornar-se sobrecarregado, se a Google solicita o sitemap com muita freqüência.

Além disso, você deve rastrear cada um XML sitemap para se certificar de que apenas inclui intercambiáveis URLs. Qualquer não-intercambiáveis URLs devem ser excluídos do XML sitemaps, tais como:

• 3xx, 4xx e 5xx páginas (e.g. redirecionado, não achei páginas, ruim, pedidos, etc)
• Erros Soft 404. Estas são páginas sem conteúdo que voltar a 200 resposta do servidor, em vez de um erro 404.
• Padronizado páginas (para além de auto-referentes URLs canônicos)
• Páginas com uma meta robots noindex directiva

(…) (…)

• Páginas com noindex X-Robots-Tag no cabeçalho HTTP

HTTP/1.1 200 OK Date: Tue, 10 de Novembro de 2017 17:12:43 GMT (…) X-Robots-Tag: noindex (…)

• Páginas bloqueadas a partir do robots.txt arquivo

Edifício limpo XML sitemaps pode ajudar a monitorar o verdadeiro indexação níveis do novo site, uma vez que vai viver. Se você não fizer isso, vai ser muito difícil de detectar qualquer indexação de assuntos.

Dica profissional: faça o Download e abra cada um sitemap XML do Excel para obter uma visão detalhada de todos os atributos adicionais, tais como hreflang ou atributos de imagem.

Sitemap HTML revisão

Dependendo do tamanho e do tipo de site que está a ser migrado, tendo um sitemap HTML pode, em certos casos, pode ser benéfico. Um sitemap HTML que consiste de URLs que não são ligados ao site principal de navegação pode aumentar significativamente a página de descoberta e de indexação. No entanto, evitar gerar um sitemap HTML que inclui muitos URLs. Se você precisa de incluir milhares de URLs, considere a construção de um segmentada sitemap HTML.

O número de aninhados sitemaps, bem como o número máximo de URLs que você deve incluir em cada um sitemap depende do site da entidade. A maior autoridade de um website, maior o número de aninhados sitemaps e URLs que poderiam fugir.

Por exemplo, o NYTimes.com sitemap HTML é composto de três níveis, onde cada um inclui mais de 1.000 URLs por sitemap. Estes aninhadas do HTML sitemaps ajuda rastreadores de mecanismo de pesquisa na descoberta de artigos publicados, a partir de 1851, que de outra forma seria difícil de descobrir e de índice, como nem todos eles teriam sido internamente ligados.

O NYTimes sitemap HTML (nível 1)

O NYTimes sitemap HTML (nível 2)

Estruturado de análise de dados

Erros na marcação estruturada de dados devem ser identificadas o mais cedo para que haja tempo para corrigi-los antes que o novo site vai viver. Idealmente, você deve testar cada modelo de página (em vez de cada página) usando o Teste de Dados Estruturados ferramenta.

Certifique-se de verificar a marcação no ambiente de trabalho e as páginas para dispositivos móveis, especialmente se o site mobile não é sensível.

A ferramenta irá apenas relatar quaisquer erros existentes, mas não omissões. Por exemplo, se a página de seu produto modelo não incluir o Produto estruturado esquema de dados, a ferramenta não relatório de erros. Assim, além de verificar a existência de erros você também deve certificar-se que cada página modelo inclui a adequada marcação estruturada de dados para o seu tipo de conteúdo.

Por favor, consulte o Google documentação para mais atualizado detalhes sobre o estruturada de implementação de dados e tipos de conteúdo suportados.

JavaScript rastreamento de revisão

Você deve testar cada modelo de página do novo site para certificar-se de que a Google será capaz de rastrear o conteúdo requer JavaScript análise. Se você é capaz de usar o Google para Buscar e Processar ferramenta em seu site de preparo, você deve definitivamente fazer isso. Caso contrário, realize alguns testes manuais, seguindo Justin Brigg conselhos.

bfead4473.55440902.png” dados de imagem=”3ljs6ksvzf8i”/>

Como Bartosz Góralewicz testes provou, mesmo se o Google é capaz de rastrear e indexar o JavaScript conteúdo gerado, não significa que ele é capaz de rastrear o conteúdo em JavaScript em todos os principais frameworks de JavaScript. A tabela a seguir resume Bartosz conclusões, mostrando que alguns frameworks de JavaScript não estão SEO-friendly, com AngularJS sendo o mais problemático de todos.

Bartosz também achei que outros motores de busca (como o Bing, Google e Baidu) realmente luta com a indexação de JavaScript, o conteúdo gerado, o que é importante para saber se o tráfego do seu site depende de qualquer destes motores de busca.

Felizmente, isso é algo que vai melhorar ao longo do tempo, mas com a crescente popularidade dos frameworks de JavaScript em desenvolvimento web, este deverá ser elevado até na sua lista de verificação.

Finalmente, você deve verificar se os recursos externos estão sendo bloqueados. Infelizmente, isso não é algo que você possa controlar 100% porque muitos recursos (tais como arquivos JavaScript e CSS) são hospedados pelos sites de terceiros que podem estar bloqueando-las através de seu próprio robots.txt arquivos!

Novamente, a Buscar e Processar ferramenta pode ajudar a diagnosticar este tipo de problema que, se não resolvidos, podem ter um impacto negativo significativo.

Mobile site SEO revisão

Ativos de revisão de bloqueio

Primeiro, certifique-se de que o robots.txt arquivo não está bloqueando acidentalmente qualquer código JavaScript, CSS, ou arquivos de imagem, que são essenciais para o mobile site de conteúdo para renderizar. Isso poderia ter um impacto negativo sobre a forma como os motores de busca processar e indexar o site móvel do conteúdo da página, que por sua vez poderia afetar negativamente o mobile site de pesquisa de visibilidade e de desempenho.

Móvel-primeiro índice de revisão

A fim de evitar quaisquer problemas associados com móvel do Google-o primeiro índice, analise cuidadosamente o mobile site e fazer, não há qualquer incompatibilidade entre o desktop e mobile sites nas seguintes áreas:

• Títulos das páginas
• Descrições de Meta
• Títulos
• Cópia
• Tag Canonical
• Meta robots atributos (i.e. noindex, nofollow)
• Ligações internas
• Dados estruturados

Um site responsivo deve oferecer o mesmo conteúdo, os links, e a marcação através de dispositivos, e acima de SEO atributos devem ser idênticos em toda a área de trabalho móvel e web sites.

Além dos acima, você deve realizar algumas técnicas adicionais, verifica dependendo o site móvel do conjunto de backup.

Ágil na análise do site

Um site responsivo devem servir a todos os dispositivos do mesmo código HTML, que é ajustado (através do uso de CSS), dependendo do tamanho da tela.

O Googlebot é capaz de detectar automaticamente este móvel configuração de tempo permitido para rastrear a página e os seus bens. É, portanto, extremamente importante para se certificar de que o Googlebot pode acessar todos os bens essenciais, tais como imagens, JavaScript, e CSS.

Ao sinal de navegadores que uma página é ágil, uma meta=”viewport” tag deve ser no lugar, dentro do de cada página HTML.

Se a marca meta viewport está faltando, tamanhos de fonte podem aparecer de forma inconsistente, o que pode causar Google para tratar a página como não compatível com dispositivos móveis.

Móvel separado URLs revisão

Se o site mobile usa URLs separadas da área de trabalho, certifique-se de que:

Cada página da área de trabalho tem uma marca apontando para o telemóvel correspondente URL.

Cada página tem um rel=”canonical” tag apontando para a correspondente área de trabalho URL.

Quando o ambiente de trabalho URLs são solicitados em dispositivos móveis, eles são redirecionados para o respectivo móvel URL.

Redirecionamentos funcionam em todos os dispositivos móveis, incluindo Android, iPhone e Windows phone.

Não há qualquer irrelevante ligações cruzadas entre o desktop e mobile páginas. Isso significa que os links internos sobre encontrado em uma página da área de trabalho só deve ligar para desktop páginas e aqueles encontrados em uma página móvel só deve ligar a outras páginas para dispositivos móveis.

O móvel URLs um retorno de 200 a resposta do servidor.

Exibição dinâmica de revisão

Exibição dinâmica de sites de servir o código diferente para cada dispositivo, mas a mesma URL.

Na dinâmica de veiculação de sites, avaliar se a variação de cabeçalho HTTP tenha sido corretamente configurado. Isso é necessário porque a dinâmica servindo sites alterar o HTML para o usuário móvel agentes e a variar cabeçalho HTTP ajuda o Googlebot descobre o conteúdo móvel.

Móveis facilidade de revisão

Independentemente de o site móvel de set-up (responsivo, separe os URLs dinâmicos ou dose), rever as páginas usando um agente do utilizador do telemóvel e certifique-se de que:

O visor foi definido corretamente. Usando uma largura fixa visor através de dispositivos irá causar problemas de usabilidade.

O tamanho de tipo de letra não é muito pequeno.

Elementos de toque (por exemplo, botões, links) não estão muito perto.

Não há qualquer intrusiva intersticiais, tais como Anúncios, lista de discussão formulários de inscrição, Download de Aplicativo de pop-ups, etc. Para evitar problemas, você deve usar tanto o uso de uma pequena HTML ou banner de imagem.

Páginas para dispositivos móveis que não são demasiado lento para carregar (veja a próxima seção).

Móvel do Google-friendly ferramenta de teste pode ajudar a diagnosticar a maioria dos problemas acima:

Móvel do Google-friendly ferramenta de teste em ação

AMPLIFICADOR de revisão do site

Se há um AMP site e uma versão desktop do site está disponível, certifique-se de que:

• Cada não-AMP página (por exemplo, ambiente de trabalho, dispositivos móveis) tem uma marca apontando para o correspondente AMP URL.
• Cada AMP página tem um rel=”canonical” tag apontando para a correspondente página da área de trabalho.
• Qualquer AMP página que não tem um correspondente área de trabalho URL tem uma auto-referindo-se canonical tag.

Você também deve certificar-se de que os Amplificadores são válidas. Isso pode ser testado usando o AMP Ferramenta de Teste.

Conteúdo misto erros

Com o Google empurrando duro para sites de ser totalmente seguro e o Chrome, tornando-se o primeiro navegador a bandeira HTTP páginas não seguras, pretendem lançar o novo site em HTTPS, certificando-se de todos os recursos, como imagens, arquivos CSS e JavaScript são solicitados através de secure conexões HTTPS.Isso é essencial para evitar conteúdo misto problemas.

Conteúdo misto ocorre quando uma página é carregado através de uma conexão segura HTTPS pedidos de ativos mais inseguro conexões HTTP. A maioria dos browsers para bloquear perigoso solicitações HTTP ou apenas exibir avisos que prejudicam a experiência do usuário.

Conteúdo misto erros no Chrome JavaScript Console

Há muitas maneiras de identificar misto de erros de conteúdo, incluindo o uso de rastreador de aplicativos, o Google Farol, etc.

Recursos de imagem com revisão

O Google indexar imagens com menos freqüência do que as páginas HTML. Se a migração de um site de imagens a partir de um local para outro (e.g. do seu domínio para um CDN), existem maneiras para ajudar o Google a) em descobrir as migrado imagens mais rapidamente. A construção de uma imagem XML sitemap vai ajudar, mas você também precisa certificar-se de que o Googlebot pode acessar o site de imagens de quando o rastreamento do site. A parte complicada de indexação de imagens é que a página da web onde aparece uma imagem bem como o ficheiro da imagem propriamente dito para ser indexada.

Site de avaliação de desempenho

Por último, mas não menos importante, a medida que o site antigo do tempo de carregamento das páginas e ver como estas se comparam com o novo site, quando este se torna disponível na encenação. Nesta fase, o foco na rede independente de aspectos de desempenho, tais como o uso de recursos externos (imagens, JavaScript, e CSS), o código HTML, e a configuração do servidor web. Mais informações sobre como efectuar este procedimento está disponível mais abaixo.

De acompanhamento do google Analytics revisão

Certifique-se de que o acompanhamento do google analytics está corretamente configurado. Esta revisão deve, preferencialmente, ser realizado por um especialista do google analytics consultores que vai olhar, para além da aplicação do código de acompanhamento. Certifique-se de que as Metas e os Eventos estão corretamente configurado, o acompanhamento de comércio eletrônico é implementado, avançado monitoramento de comércio eletrônico é ativado, etc. Não há nada mais frustrante do que não ter dados do google analytics após o seu novo site é lançado.

Redirecionamentos de testes

Teste o redireciona antes que o novo site entrar no ar é crítica e pode poupar-lhe um monte de problemas mais tarde. Há muitas maneiras de verificar os redirecionamentos em um teste/test server, mas a linha inferior é que você não deve lançar o novo site sem ter testado o redireciona.

Uma vez que a redireciona ficarem disponíveis no preparo/ambiente de teste, o rastreamento de toda a listagem de páginas de redirecionamento e verifique os seguintes problemas:

• Redirecionar loops (uma URL que infinitamente redireciona para si)
• Redirecionamentos com um 4xx ou 5xx de resposta do servidor.
• Redirecionar correntes (uma URL que redireciona para outra URL, que por sua vez redireciona para outra URL, etc.).
• URLs canônicos que retornam um 4xx ou 5xx de resposta do servidor.
• Canonical loops (página tem Um canônica apontando para a página B, que tem uma canônico apontando para Uma página).
• Canonical correntes (uma canônico que aponta para outra página que tem um canônica apontando para outra página, etc.).
• Protocolo/host inconsistências e.g. URLs são redirecionado para HTTP e HTTPS URLs ou www e não www URLs.
• Inicial/final caracteres de espaço em branco. O uso de trim() no Excel para eliminá-los.
• Caracteres inválidos em URLs.

Dica profissional: certifique-se de que um dos antigos do site URLs redirecione para a URL correta no novo site. Nesta fase, porque o novo site ainda não existir, você só pode testar se o redirecionamento de URL de destino é o pretendido, mas é definitivamente vale a pena. O fato de que uma URL de redirecionamentos, isso não significa que redireciona para a página direita.

Fase 4: dia do Lançamento atividades

Quando o site está em baixo…

Enquanto o novo site está substituindo o velho, as chances são de que o site vivo vai ser temporariamente para baixo. O tempo de inatividade deve ser mantido a um mínimo, mas enquanto isso acontece, o servidor web deve responder a qualquer solicitação de URL com uma 503 (serviço indisponível) a resposta do servidor. Isto irá dizer-rastreadores de mecanismo de pesquisa que o site está temporariamente fora do ar para manutenção, de modo que eles voltem para rastrear o site mais tarde.

Se o site estiver em baixo por muito tempo sem que serve uma 503 resposta do servidor e motores de busca rastrear o website de busca orgânica visibilidade vai ser afetado negativamente e de recuperação não ser imediata uma vez o site está de volta. Além disso, enquanto o site está temporariamente fora do ar deve servir, também, um informativo página de espera para notificar os usuários de que o site está temporariamente desativado para manutenção.

Técnico de verificações no local

Assim que o novo site tem ido viver, dar uma rápida olhada em:

O robots.txt arquivo para se certificar de que os motores de busca não são bloqueados para rastreamento

As principais páginas de redirecionamento (por exemplo, fazer solicitações para o site antigo superior páginas de redirecionamento corretamente?)

Páginas principais tag canonical

Páginas principais respostas do servidor

Noindex/nofollow directivas, em caso de não-intencional

As verificações devem ser efectuadas através de ambos os sites para celular e computador, a menos que o site é totalmente sensível.

Pesquisa Console de ações

As seguintes atividades devem acontecer assim que o novo site tem ido ao vivo:

Testes e fazer o upload do sitemap XML(s)

Definir o local de preferência do domínio (www ou sem www)

Conjunto Internacional de segmentação (se aplicável)

Configurar os parâmetros de URL para enfrentar início de qualquer potencial de problemas de conteúdo duplicado.

Carregar a Rejeição de arquivo (se aplicável)

Use a ferramenta de Alteração de Endereço (se mudar de domínios)

Dica profissional: Usar o “Buscar como o Google” recurso para cada diferente tipo de página (por exemplo, a página inicial, uma categoria e uma subcategoria, a página de um produto) para certificar-se de que o Googlebot pode renderizar as páginas, sem quaisquer problemas. Revisão de casos notificados de recursos bloqueados e não se esqueça de usar a Busca e processamento para desktop e móvel, especialmente se o site mobile não é sensível.

Bloqueado recursos impedir que o Googlebot renderizar o conteúdo da página

Fase 5: Pós-lançamento de revisão

Uma vez que o novo site tem ido viver, uma nova rodada de profundidade devem ser realizadas verificações. Estas são em grande parte os mesmos que os mencionados no “Fase 3: Pré-lançamento do Ensaio” seção.

No entanto, a principal diferença nesta fase é que agora você tem acesso a muito mais dados e ferramentas. Não subestime a quantidade de esforço que você precisa para colocar durante esta fase, porque todos os problemas que encontro agora afeta diretamente o desempenho do site nas SERPs. Por outro lado, quanto mais cedo um problema fica identificado, mais rápido ele será resolvido.

Além de repetir as mesmas tarefas de teste que foram descritos na Fase 3 da seção, em certas áreas, as coisas podem ser testados de forma mais minuciosa, com precisão, e em maior detalhe. Agora você pode tirar proveito de Pesquisa de recursos do Console.

Verificação de rastreamento de estatísticas e logs do servidor

Manter um olho sobre as estatísticas de rastreamento disponíveis na Pesquisa Console, certifique-se de que o Google rastrear as novas páginas do site. Em geral, quando o Googlebot vem em novas páginas tende a acelerar o número médio de páginas que ele rastreia por dia. Mas se você não pode manchar um pico em torno do momento da data de lançamento, algo que pode estar afetando negativamente a capacidade do Googlebot para rastrear o site.

Estatísticas de rastreamento de Pesquisa do Google Console

Analisar os arquivos de log do servidor é de longe a maneira mais eficaz de detectar qualquer rastrear problemas ou ineficiências. Ferramentas como Botify e No Rastreamento pode ser extremamente útil porque eles combinam rastreamentos com dados de log do servidor e pode realçar páginas os motores de busca não rastrear as páginas que não são ligados internamente (órfãos páginas), de baixo valor as páginas que são fortemente internamente ligados, e muito mais.

Revisão de erros de rastreamento regularmente

Manter um olho sobre o relatado erros de rastreamento, de preferência diariamente, durante as primeiras semanas. Baixar esses erros diariamente, rastrear URLs reportados, e tomando as ações necessárias (por exemplo, implementar adicionais redirecionamentos 301, correção soft 404 erros) ajuda a uma recuperação mais rápida. É altamente improvável que você vai precisar redirecionar a cada 404 que é relatado, mas você deve adicionar redireciona para as mais importantes.

.net/site-migração-guia/5a9f6c06974938.73837847.png” dados de imagem=”bbm2bgsy3wvm”/>

Dica profissional: No Google Analytics, você pode facilmente descobrir quais são os mais comumente solicitados 404 URLs e corrigir esses primeira!

Outros útil de Pesquisa de recursos do Console

Outra Pesquisa de recursos do Console de pena conferir incluem o bloqueio de Recursos, Estruturadas de Dados, erros de Usabilidade erros, Melhorias de HTML e Internacional de Segmentação (para verificar a hreflang erros reportados).

Dica profissional: Manter um olhar atento sobre os parâmetros de URL em caso de que eles estão causando problemas de conteúdo duplicado. Se este for o caso, considere a possibilidade de tirar alguns urgente de ação corretiva.

Medição de velocidade do site

Uma vez que o novo site está vivo, medir a velocidade do site para se certificar de que as páginas do site estão de carregamento rápido o suficiente para desktop e dispositivos móveis. Com a velocidade do website a ser um sinal de classificação através de dispositivos e becauseslow páginas perder usuários e clientes, comparando o novo site de velocidade com o site antigo, é extremamente importante. Se o novo site do carregamento da página vezes parece ser mais alta que você deve tomar algumas medidas imediatas, caso contrário o tráfego do seu site e as conversões quase certamente irá levar um hit.

Avaliação de velocidade usando as ferramentas da Google

Duas ferramentas que podem ajudar com isso são os do Google, o Farol e o Pagespeed Insights.

O Pagespeed Insights Ferramenta mede o desempenho da página, em ambos os móveis e dispositivos de ambiente de trabalho e mostra o mundo real página de dados de velocidade baseado em dados que o Google recolhe a partir do Chrome. Ele também verifica se uma página foi aplicado comuns as práticas recomendadas de desempenho e proporciona uma optimização de pontuação. A ferramenta inclui os seguintes principais categorias:

• Velocidade de contagem: Categoriza uma página tão Rápido, Médio ou Lento usando duas métricas: O Primeiro Contentful Pintura (FCP) e DOM Conteúdo Carregado (DCL). Uma página é considerado rápido, se ambas as métricas estão no topo de um terço de sua categoria.
• Otimização de pontuação: Categoriza uma página como Bom, Médio, ou Baixo com base no desempenho headroom.
• De carregamento da página distribuições: Categoriza uma página tão Rápido (mais rápido terceiro), Média (terço médio) ou Lenta (terço inferior) comparando-se contra todos os FCP e DCL eventos em que o Usuário do google Chrome, relato de Experiência.
• A página de estatísticas: Pode indicar-se a página pode ser mais rápido se o desenvolvedor modifica a aparência e a funcionalidade da página.
• Otimização sugestões: Uma lista de melhores práticas que podem ser aplicadas a uma página.

Google PageSpeed Insights em ação

O Google Farol é muito útil para o desempenho do dispositivo, a acessibilidade e a Progressiva Web Apps auditorias. Ele oferece várias métricas úteis que podem ser usados para medir o desempenho da página, em dispositivos móveis, tais como:

• Primeiro Significativa de Pintura que medidas quando o conteúdo principal de uma página é visível.
• Tempo para Interactivo é o ponto em que a página está pronta para um usuário interaja com ele.
• Índice de velocidade de medidas que mostra o quão rápido uma página são visivelmente preenchido

Ambas as ferramentas fornecem recomendações para ajudar a melhorar qualquer site denunciado problemas de desempenho.

O Google Farol em ação

Você também pode usar essa ferramenta do Google para obter uma estimativa da percentagem de usuários que você pode estar perdendo a partir do seu telemóvel páginas do site devido à lentidão do tempo de carregamento das páginas.

A mesma ferramenta também fornece uma indústria de comparação para você ter uma idéia de quão longe você está de sites com melhor desempenho em seu setor.

Medir a velocidade de usuários reais

Depois que o site tenha ido ao vivo, você pode começar a avaliar a velocidade do site com base nos usuários a visitar o seu site. Se você tiver o Google Analytics, você pode facilmente comparar o novo site da média do tempo de carregamento com a anterior.

Além disso, se você tem acesso a um Usuário Real ferramenta de Monitoramento, como Pingdom, você pode avaliar a velocidade do site com base nos usuários a visitar o seu site. O mapa abaixo ilustra como diferentes visitantes uma experiência muito diferentes tempos de carregamento, dependendo de sua localização geográfica. No exemplo abaixo, o tempo de carregamento das páginas parecem ser satisfatórios para os visitantes do reino UNIDO, EUA e Alemanha, mas para os usuários que residem em outros países eles são muito mais elevados.

Fase 6: local de Medição de desempenho de migração

Quando a medida

Tem o site de migração foi bem sucedido? Esta é a grande questão que todos os envolvidos gostariam de saber a resposta, assim que o novo site vai viver. Na realidade, quanto mais você esperar, mais clara a resposta torna-se, como a visibilidade durante as primeiras semanas ou mesmo meses pode ser muito volátil, dependendo do tamanho e a autoridade do seu site. Para sites pequenos, uma 4-6 semana período deve ser suficiente antes de comparar o novo site da visibilidade com o site antigo. Para grandes sites que você pode ter que esperar por pelo menos 2-3 meses antes da medição.

Além disso, se o novo site é significativamente diferente da anterior, os usuários vão precisar de algum tempo para se acostumar com o novo olhar e sentir, e adaptam-se com a nova taxonomia, viagens usuário, etc. Tais alterações, inicialmente, ter um impacto negativo significativo no site da taxa de conversão, o que deve melhorar depois de algumas semanas os visitantes de retorno estão ficando mais e mais usado para o novo site. Em qualquer caso, fazendo de dados orientado a conclusões sobre o novo site UX pode ser arriscado.

Mas estes são apenas regras gerais do polegar e precisam ser levados em consideração, juntamente com outros fatores. Por exemplo, se alguns dias ou semanas após o novo site de lançamento significativas foram efectuadas alterações adicionais (por exemplo, para resolver um problema técnico), a migração de avaliação deve ser empurrado mais para trás.

Como medir

Medição de desempenho é muito importante e, apesar de as empresas interessadas só estaria interessado em ouvir sobre as receitas de tráfego e impacto, há um monte de outras métricas que você deve prestar atenção. Por exemplo, pode haver várias razões para a receita vai para baixo depois de uma migração do site, incluindo tendências sazonais, menor marca de juros, UX questões que reduziu significativamente o site da taxa de conversão, pobres móvel desempenho, baixo tempo de carregamento das páginas, etc. Além disso, o tráfego orgânico e valores das receitas, também preste atenção ao seguinte:

• O ambiente de trabalho e móveis de visibilidade (a partir de SearchMetrics, Alexa, Sistrix)
• Área de trabalho móvel e classificações (de qualquer confiável rank ferramenta de acompanhamento)
• O envolvimento do usuário (taxa de rejeição, tempo médio na página)
• Sessões por tipo de página (i.e. são as páginas de categoria de condução como muitas sessões como antes?)
• Taxa de conversão por tipo de página (i.e. são as páginas de produto a conversão da mesma forma como antes?)
• Taxa de conversão por dispositivo (i.e. tem o desktop/mobile taxa de conversão aumentou/diminuiu desde o lançamento do novo site?)

A revisão a seguir também pode ser muito prático, especialmente a partir de uma técnica de solução de problemas de perspectiva:

• Número de páginas indexadas (Pesquisa Console)
• Enviado vs páginas indexadas no XML sitemaps (Pesquisa Console)
• Páginas que recebem pelo menos uma visita (google analytics)
• A velocidade do website (PageSpeed Insights, o Farol, o Google Analytics)

Só depois de já procurei em todas as áreas acima, que você pode concluir, com segurança, se a migração foi bem-sucedida ou não.

Boa sorte e se precisar de qualquer consulta ou a assistência com a sua migração do site, favor entrar em contato!

Site de migração lista de verificação

A data de migração do site a lista de verificação está disponível para download a partir do nosso site. Por favor, note que a lista de verificação é regularmente actualizado para incluir todas as áreas críticas para o sucesso de uma migração do site.

Anexo: ferramentas Úteis

Rastreadores

• Gritando Sapo: O SEO canivete Suíço, ideal para o rastreamento de pequenas e médias empresas de web sites.
• Sitebulb: Muito intuitivo aplicativo rastreador com uma bela interface, muito bem organizado relatórios, e muitos úteis visualizações de dados.
• Profundidade de Rastreamento: baseado em Nuvem rastreador com a capacidade de rastreamento de preparo sites e fazer o rastreamento de comparações. Permite comparações entre diferentes rastreia e lida bem com grandes sites.
• Botify: Outro poderoso baseado em nuvem rastreador suportados pelo excepcional arquivo de log do servidor recursos de análise que pode ser muito esclarecedora em termos de entendimento de como os mecanismos de pesquisa rastrear o website.
• No Rastreamento: Rastreador e server log analyzer para a empresa de SEO auditorias com muitos recursos úteis para identificar o rastreamento de orçamento, a qualidade do conteúdo, e problemas de desempenho.

Prático Chrome add-ons

• Web developer: Uma coleção de ferramentas de desenvolvimento, incluindo maneiras fáceis para habilitar/desabilitar o JavaScript, CSS, imagens, etc.
• User agent switcher: Alternar entre diferentes agentes do usuário, incluindo o Googlebot, móveis, e outros agentes.
• Ayima Caminho de Redireccionamento: Um grande cabeçalho e redirecionar verificador.
• SEO Meta em 1 clique: Uma página de meta-atributos, cabeçalhos e links inspetor.
• Raspador: Uma maneira fácil para raspar o website de dados em uma planilha.

Ferramentas de monitoramento de Site

• Uptime Robot: site Grátis monitoramento de uptime.
• Robotto: Livre robots.txt ferramenta de monitoramento.
• Pingdom tools: Monitores site uptime e a velocidade a página de usuários reais (RUM de serviço)
• SEO Radar: Monitora todos os críticos de SEO elementos e dispara alertas quando estas mudanças.

Site ferramentas de desempenho

• PageSpeed Insights: Medidas de desempenho da página para celulares e computadores. Ele verifica se uma página foi aplicado comuns as práticas recomendadas de desempenho e proporciona uma pontuação, que varia de 0 a 100 pontos.
• Farol: a Calhar extensão do google Chrome para o desempenho, acessibilidade, Progressiva Web Apps auditorias. Também pode ser executado a partir da linha de comando, ou como um Nó do módulo.
• Webpagetest.org: Muito detalhado página de testes a partir de vários locais, conexões e dispositivos, incluindo detalhados gráficos em cascata.

De teste de dados estruturados ferramentas

• O Google está estruturado ferramenta de teste de dados e o Google está estruturado de dados, ferramenta de teste de extensão do google Chrome
• Bing markup validator
• Yandex ferramenta de teste de dados estruturados
• O Google rica resultados de ferramenta de teste

Móveis de ferramentas de teste

• Móvel do Google-friendly ferramenta de teste
• Google AMP ferramenta de teste
• AMP validador ferramenta

Backlink fontes de dados

• Ahrefs
• O Majestic SEO