Por que construtores de sites podem ser terríveis para o seu SEO

seo
Compartilhar no facebook
Compartilhar no twitter
Compartilhar no pinterest
Compartilhar no whatsapp

Sumário

Vou fazer uma afirmação ousada:

Os construtores de páginas são terríveis para seu SEO.

Cada um deles.

Eles não oferecem vantagem de SEO.

Por fim, esses construtores de sites OQVVOVO (“O que você vê é o que você obtém”) limitarão severamente o crescimento do seu negócio.

A marcação HTML criada por qualquer construtor de páginas sempre será exponencialmente mais inchada do que o HTML feito à mão por um desenvolvedor web especializado.

A pessoa comum pode perguntar: “Quem se importa com a aparência do código, desde que eu tenha um design bonito no navegador?”

Eis por que isso importa …

OQVVOVO?

Este é um aplicativo de software para projetar seu site, onde você simplesmente posiciona seus elementos gráficos de texto onde deseja, e o software grava o HTML, PHP, CSS e JavaScript necessários para que ele funcione.

Se você não é muito técnico, pode estar pensando: “O que há de errado nisso, Jeremy? Parece muito mais rápido e fácil do que aprender tudo o que eu preciso saber para criar meu próprio site, e é muito mais barato do que contratar uma agência.”

Se é aí que está sua cabeça, você está correto nos dois aspectos.

Mas esses criadores de sites ainda são uma péssima escolha para qualquer negócio sério e de longo prazo.

Para entender o porquê, vamos primeiro examinar o histórico dos editores OQVVOVO, como o cenário on-line mudou e o que isso significa para os empresários e comerciantes de hoje.

O caminho para OQVVOVO

Quando as pessoas começaram a usar navegadores para navegar on-line, as páginas da Web precisavam ser meticulosamente codificadas à mão, geralmente em um editor de texto rudimentar, como o bloco de notas.

Nenhuma interface lisa. Sem destaque de sintaxe. Apenas um fundo branco onde você digitaria seu código manualmente.

Lembro-me vividamente de entrar em uma Barnes & Noble em Jacksonville, Carolina do Norte, e comprar meu primeiro livro em HTML. Isso foi em 1997.

Naquela época, foi assim que adquirimos novas habilidades porque as escolas estavam muito atrás da tecnologia atual e não tínhamos recursos surpreendentes online, como o Search Engine Journal, Stack Overflow e CSS Tricks, onde podemos encontrar instantaneamente a resposta para praticamente qualquer coisa.

E mesmo que existissem, os mecanismos de pesquisa ainda não eram avançados o suficiente nem indexaram o suficiente da Web para ajudar os usuários a encontrá-los efetivamente.

Assim, aprendemos com esses livros gigantes que geralmente tinham mais de dez centímetros de espessura e pesavam vários quilos.

Criar uma página da web foi um processo lento e trabalhoso, mas seu código geralmente era limpo e eficiente.

Obviamente, todos queriam tornar esse processo mais rápido e fácil.

O processo foi aprimorado significativamente ao incluir recursos como destaque de sintaxe e conclusão de código nos editores de texto da velha escola, mas rapidamente progrediu para a próxima etapa lógica.

Foi quando vimos ferramentas OQVVOVO como o Microsoft FrontPage e o Macromedia Dreamweaver entrar em cena. (Mais tarde, a Macromedia foi comprada pela Adobe.)

Alguns web designers ficaram com editores de texto, mas mais pessoas começaram a migrar para os editores OQVVOVO devido à sua simplicidade.

Em vez de precisar aprender e lembrar de centenas de elementos HTML, agora você pode criar um site com a mesma facilidade com que cria um slide no PowerPoint.

Mas essa simplicidade teve um preço.

Embora o site final possa parecer incrível no front-end, o código nos bastidores que o alimentou foi um incêndio nas lixeiras.

Isso geralmente resultava em páginas da web carregadas significativamente mais lentas ou mesmo exibidas ou funcionando incorretamente em um ou mais navegadores.

Alguns web designers conheciam essas limitações e apenas usaram os editores OQVVOVO para criar um protótipo rápido de uma página da Web antes de ajustar o código manualmente.

Infelizmente, a maioria não sabia ou não se importava, o que significava que havia milhões de sites on-line que não funcionavam corretamente.

Foi por isso que, nos anos 90 e início dos anos 2000, vimos mensagens em sites informando coisas como: “Este site é melhor visualizado no Internet Explorer com uma resolução de tela de 800 × 600 ou superior”.

Com o passar do tempo, os navegadores avançaram rapidamente, assim como a tecnologia usada nos sites.

Os editores do OQVVOVO simplesmente não conseguiam acompanhar, e a maioria dos web designers de verdade começou a voltar aos sites de codificação manual.

Isso lhes permitiu produzir um código mais limpo, carregado mais rapidamente, exibido corretamente em todos os principais navegadores e com melhor classificação nos mecanismos de pesquisa.

Nos últimos anos, a maioria dos navegadores começou a renderizar páginas da Web de maneira mais consistente.

Previsivelmente, isso incentivou o ressurgimento dos editores OQVVOVO, porque agora eles geralmente podiam produzir marcações que renderizariam relativamente bem na maioria dos navegadores modernos.

Inúmeras opções surgiram.

Praticamente todas as empresas de hospedagem oferecem uma opção de terceiros ou seu próprio construtor de páginas de marca, várias empresas lançaram versões autônomas de desktop ou SAAS dos construtores de páginas, enquanto algumas ofereceram um pacote completo de construtor de páginas + hospedagem e uma infinidade de construtores de páginas WordPress e Drupal plugins inundaram o mercado.

O que há de errado com o OQVVOVO?

Velocidade da página

Um site de carregamento rápido é fundamental para criar uma experiência positiva para o usuário e tem um impacto significativo em:

  • Quanto tempo os visitantes permanecem no seu site.
  • Quantos visitantes convertem em compradores.
  • Quanto você paga por clique em pesquisa paga.
  • Onde você classifica na pesquisa orgânica.

Aqueles de nós que priorizam a velocidade da página tendem a se concentrar em detalhes como o tamanho de nossas imagens, o número de scripts e os formatos de mídia ideais, mas geralmente ignoram o impacto da marcação HTML na velocidade da página.

Em muitos casos, as pessoas nem percebem que isso tem impacto.

Pense assim: cada byte aumenta a quantidade de tempo que uma página da Web leva para carregar. Embora possam parecer insignificantes individualmente, aumentam rapidamente.

E vai além do tamanho do próprio arquivo HTML.

Cada elemento é tratado como um nó individual. Quanto mais nós houver, mais tempo leva para o navegador processar e renderizar a página após o download.

O problema é multiplicado por elementos aninhados.

Muitos elementos aninhados podem fazer com que o desempenho sofra ainda mais devido ao poder de processamento adicional necessário para renderizar a página corretamente.

Os construtores de páginas atingem um layout específico, aninhando ineficientemente vários elementos.

E depois aninhando,

  e aninhamento,

    e aninhamento,

      e aninhamento.

Você entendeu.

chrome console

Sua interface simples de arrastar e soltar é focada apenas na aparência do front end e não possui a capacidade de otimizar o HTML nos bastidores.

Um design específico pode resultar em milhares de elementos quando produzido por um construtor de páginas, enquanto um designer experiente pode conseguir a mesma aparência com apenas algumas centenas de elementos.

A diferença de velocidade entre um site com design profissional e um produzido por um construtor de páginas popular é espantosa.

google pagespeed

Mas os problemas não param por aí.

Marcação HTML

O HTML válido do W3C é importante porque é mais provável que uma página da Web com HTML válido seja exibida e funcione corretamente.

Também é importante porque sua marcação HTML envia certos sinais para os mecanismos de pesquisa.

Outra maneira de analisar isso é ajudá-los a entender melhor seu conteúdo.

Quando eles conseguem entender melhor seu conteúdo, supondo que ele se encaixe no que os pesquisadores estão procurando, suas páginas da web geralmente são mais altas e ganham mais tráfego orgânico.

Não sou um purista que insiste em que todas as páginas de todos os sites precisam ser 100% válidas em HTML 100% do tempo.

Apoio o princípio da validação de HTML em geral, mas há muitos casos em que os erros são insignificantes e / ou não valem tempo, mão de obra e dinheiro para corrigir.

Há muita área cinzenta no mundo real.

Mas esses criadores de sites levam os erros de validação HTML a um nível totalmente novo.

seo check

Simplesmente não há desculpa para uma página da Web ter quase 600 erros de validação HTML!

Alguns desses erros estão causando problemas de aparência e funcionalidade, o que inevitavelmente prejudica a experiência e a classificação do usuário.

Mas esses erros de HTML – que você não consegue corrigir – descobrem outro problema ainda maior.

Você não tem acesso ao seu código

Para resolver e corrigir adequadamente os problemas técnicos de SEO no local, você precisa de acesso total ao HTML por trás do seu site.

Mas você não tem acesso a isso com esses construtores.

Você só tem o editor OQVVOVO do front end .

Ao usar o WordPress, Drupal ou qualquer outra plataforma de código aberto, você pode fazer literalmente o que quiser com seu site.

Isso é importante porque cada site terá necessidades diferentes e essas necessidades mudarão com o tempo.

Há um número enorme de tarefas que você pode precisar executar para melhorar o SEO no local.

Essas tarefas vão muito além dos detalhes básicos, como tags de título e título, slugs de URL, dados estruturados, URLs canônicos ou meta descrições.

Claro, você pode adicionar HTML a uma página, mas não pode editar o HTML que já está lá.

Esse é um problema monumental para qualquer negócio sério.

Já abordamos a infinidade de problemas gerais de desempenho e validação de HTML, mas há muitos outros problemas mais específicos que podem surgir.

Por exemplo, algo que costumo fazer é modificar a estrutura de URL das categorias de blog e depois modificar as trilhas de navegação para representar com precisão a nova estrutura de URL.

Isso exigia a capacidade de modificar o código PHP que alimenta um site.

Ou pode ser necessário configurar redirecionamentos após excluir uma grande quantidade de conteúdo antigo .

Bem, com um construtor de sites, você fica preso manualmente configurando cada redirecionamento individual, em oposição a uma plataforma tradicional onde você tem acesso ao seu. arquivo htaccess ou web.config e geralmente pode criar os redirecionamentos apropriados para todo o conteúdo excluído com apenas algumas linhas de código.

Em sites maiores, a capacidade de modificar HTML e seu banco de dados diretamente frequentemente permite corrigir rapidamente problemas para um grande número de páginas de uma só vez.

Isso pode incluir:

  • Alterando como uma parte específica do seu tema é marcada.
  • Adicionando ou removendo um elemento crítico em todo o site.
  • Atualizando um link específico no conteúdo de várias páginas do seu site.

Como você não tem acesso ao código nos bastidores, não é possível ajustar o desempenho do seu site.

Isso é essencial porque a otimização da velocidade é uma ciência e uma arte, e o que funciona para um site pode diminuir a velocidade ou até quebrar outro site.

Há muitas tentativas e erros envolvidos.

Mas os criadores de sites não oferecem a capacidade de fazer nada sobre isso, o que é insano, considerando sua velocidade abismal.

Há um número ilimitado de possíveis problemas de SEO no local que você pode encontrar e que simplesmente não pode corrigir se estiver usando um construtor de sites.

Os construtores de sites não limitam apenas o SEO técnico – eles também limitam as opções de negócios

A incapacidade de editar diretamente o HTML do seu site cria problemas que vão além do SEO.

Por exemplo, minha agência está criando um site para um grande empreiteiro que oferece uma variedade de serviços em vários locais.

Criamos um sistema no qual eles podem simplesmente inserir o tipo de serviço e as informações de contato em um conjunto de campos personalizados para uma página específica e, em seguida, essa página exibirá seu endereço e número de telefone exclusivos no rodapé, agrupados nos bastidores da maneira apropriada. marcação de esquema.

Para qualquer página que não possua dados nesses campos personalizados, o padrão é o esquema e as informações de contato corporativas.

Você nunca poderia fazer algo assim em um construtor de sites.

No entanto, ao usar uma plataforma de código aberto como o WordPress, você geralmente pode encontrar um plugin para realizar praticamente qualquer coisa que possa imaginar.

E, nos raros casos em que você não pode, pode desenvolvê-lo sozinho ou contratar um desenvolvedor.

Empresas sérias devem evitar construtores de sites

Existem muitas desvantagens no uso de criadores de sites.

Acredito que qualquer empresário sério deva evitar essas plataformas como a praga.

Uma opção muito melhor é escolher uma plataforma de código aberto como o WordPress, que você pode instalar e encontrar temas gratuitos ou baratos, se estiver com um orçamento apertado, ou contratar um freelancer ou agência para lidar com tudo isso para você.

Qualquer tempo, recursos e dinheiro investidos em um site simples de criação de sites serão desperdiçados, pois você terá que começar de novo quando estiver pronto para levar a sério sua presença on-line.

Compartilhe esse post com seus amigos

Compartilhar no facebook
Compartilhar no google
Compartilhar no twitter
Compartilhar no linkedin

Deixe um Comentário