Você já se deparou com uma situação em que precisou ter um blog no site da sua empresa que não é executado no WordPress? Tenho certeza de que a maioria de vocês já se deparou com esse tipo de situação. Neste artigo, você descobrirá uma maneira de fazer isso sem comprometer o SEO. Antes de nos aprofundarmos no assunto, vamos explorar como o
Você já se deparou com uma situação em que precisou ter um blog no site da sua empresa que não é executado no WordPress? Tenho certeza de que a maioria de vocês já se deparou com esse tipo de situação.
Neste artigo, você descobrirá uma maneira de conseguir isso sem comprometer o SEO.
Antes de nos aprofundarmos no assunto, vamos explorar como as organizações e instituições fazem uso da hospedagem do blog separadamente do site principal.
Muitas empresas de grande porte têm sistemas de TI complicados, o que torna difícil para seus departamentos internos olharem para fora do escopo de seus sistemas internos. Tomemos, por exemplo, o desejo do departamento de marketing de conteúdo de criar um blog para esclarecer seu público. No entanto, o arranjo atual impossibilita a criação de um blog, por exemplo, na hospedagem do WordPress.
Por outro lado, as empresas podem usar o ".NET Framework" para seus aplicativos da Web, e outras empresas hesitam em usar estruturas de código aberto.
Quando você precisa hospedar um blog em qualquer um dos cenários listados acima, não tem outra opção a não ser pensar em um servidor alternativo para hospedá-lo. Portanto, esse servidor está fora do servidor em que você hospedou seu site. Vamos dar uma olhada em algumas dessas opções e nos impactos que elas teriam, certo?
Por exemplo, se seu site principal tiver o URL www.myorganization.com, os profissionais mais competentes tecnicamente do passado estariam inclinados a instalar o blog do WordPress comprando um subdomínio do domínio principal. Por exemplo, nessa situação, ele estaria em ourblog.myoraginzation.com.
No passado, essa solução seria perfeita. No entanto, atualmente, quando o seu objetivo é gerar uma quantidade considerável de tráfego para o seu blog, você precisa considerar também os aspectos de SEO (Search Engine Optimization). Veremos isso na próxima seção.
O principal motivo pelo qual os proprietários de sites compram subdomínios é ter conteúdo separado com base em vários produtos de sua marca. Embora também possa haver outros motivos, como um site separado para dispositivos móveis e direcionamento de tráfego, o motivo fundamental está no conteúdo e na expansão de sua marca com base em vários nichos.
Por exemplo, a Wikipédia tem subdomínios para separar o conteúdo com base em vários idiomas, como fr.wikipedia.com ou es.wikipedia.com.
A NPR, uma rede de rádio popular, é outro exemplo em que eles se concentram 100% em suas notícias e conteúdo. Entretanto, eles também têm um subdomínio, https://shop.npr.org/, que se concentra principalmente em merchandising.
Portanto, nos cenários mencionados acima, faz sentido ter um subdomínio. Mas e no caso de blogs?
Bem, os mecanismos de pesquisa consideram os subdomínios como sites separados. Isso significa que os mecanismos de pesquisa precisam rastrear e indexar cada subdomínio separadamente. Além disso, os backlinks para o domínio principal não são compartilhados com seus subdomínios. Portanto, criar a classificação da página para um subdomínio é quase tão difícil quanto para o domínio principal.
Portanto, seria útil se você tivesse subdomínios em circunstâncias em que isso fizesse sentido. Portanto, uma opção ideal em blogs seria ter o blog como um subdiretório em seu site principal.
No entanto, como mencionei acima, como você pode fazer isso em circunstâncias em que seu site principal opera e quando você o hospeda em uma plataforma diferente que não oferece suporte à hospedagem do WordPress?
É exatamente para isso que serve o Proxies reverso, e forneceremos uma visão geral do proxies reverso na próxima seção.
Entender o conceito de proxy reverso seria mais fácil se você soubesse o que faz um proxy avançado.
Encaminhamento Proxy - Um encaminhamento Proxy encaminha todas as solicitações recebidas de todos os nós da LAN (rede local) para o servidor relevante para o qual a solicitação deve ir. O servidor de destino não faz ideia da origem da solicitação e envia a resposta ao cliente que iniciou a solicitação por meio do encaminhamento proxy. O diagrama abaixo ilustra isso
Proxy reverso: Em contraste, um reverso fica na frente dos servidores e envia uma solicitação ao servidor correto quando o cliente inicia uma solicitação. Então, quando o servidor apropriado retorna a resposta, o reverso retorna a resposta ao dispositivo cliente. Para o dispositivo do cliente, pareceria que o servidor reverso processou todas as solicitações. O reverso é ideal em situações em que a mesma parte de um aplicativo da Web é reduzida em muitos servidores diferentes. Proxy proxy Proxy Proxies
Para saber mais sobre Reverse e Forward proxies, você pode consultar este artigo.
Da mesma forma, você pode usar um Reverse Proxy para direcionar o tráfego para o servidor em que você hospedou o blog do WordPress. Por outro lado, o Reverse Proxy direcionará o tráfego não relacionado ao blog para o servidor relevante. Sei que é mais fácil falar do que fazer. Então, vamos demonstrar com um exemplo.
Digamos que, conforme mostrado no diagrama abaixo, seu site esteja https://www.somedomain.com hospedado em um servidor da Web que não oferece suporte ao WordPress, mas sua equipe de marketing de conteúdo está louca para ter um blog. Assim, considerando todos os fatos de SEO mencionados acima, sua equipe de desenvolvimento da Web não tem outra opção a não ser instalar o blog no diretório "blog". Portanto, o URL do blog apareceria como https://www.somedoamin.com/blog.
Como o site principal não é compatível com o WordPress, aqui estão as etapas que sua equipe de desenvolvimento web deve seguir:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="blog.somedomain.com" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern="^blog.somedomain.com$" />
<add input="{PATH_INFO}" pattern="^/blog/" negate="true" />
</conditions>
<action type="Rewrite" url="\blog\{R:0}" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Nas duas linhas abaixo, o "blog.somedomain.com" deve ser substituído pelo subdomínio em que o blog está localizado:
<rule name="blog.somedomain.com" stopProcessing="true">
<add input="{HTTP_HOST}" pattern="^blog.somedomain.com$" />
Em seguida, nessas duas linhas, você pode substituir a pasta "blog" se tiver dado um nome diferente a ela:
<add input="{PATH_INFO}" pattern="^/blog/" negate="true" />
<action type="Rewrite" url="\blog\{R:0}" />
Na etapa final, embora tenhamos usado um subdomínio, isso não afetará o SEO, pois o tráfego será gerado para a pasta do blog do site principal. Portanto, o redirecionamento para o subdomínio é um processo interno que não afetaria o SEO.
As circunstâncias discutidas acima são quando você está executando um servidor que não oferece suporte a PHP. No entanto, se você se deparar com um cenário em que seu site principal esteja executando PHP ou Drupal, por exemplo, mas quiser ter um site diferente para o blog no mesmo domínio, será necessário configurar o Proxy reverso de acordo com as etapas abaixo.
Mas, antes disso, você precisa ter certeza de que tem dois sites em funcionamento. Um deles é https://www.somedomain.com, e o outro é com o WordPress instalado com subdomínio, https://blog.somedomain.com.
Em primeiro lugar, você precisa abrir o terminal do servidor Apache via SSH. Em seguida, você precisa ativar o módulo proxy do Apache usando este comando:
sudo a2enmod proxy proxy _http ssl
Esse comando reiniciará o Apache na maioria das ocasiões para recarregar as novas diretivas que você definiu acima:
Em seguida, vem a etapa que você estava esperando. Trata-se de criar o proxy reverso editando o arquivo de host virtual do servidor.
<VirtualHost *>
DocumentRoot /var/www/app/public
SSLProxyEngine On ProxyRequests off
ProxyPass /blog http://blog.somedomain.com
ProxyPassReverse /blog http://blog.somedomain.com
</VirtualHost>
Dois pontos vitais a serem observados aqui são:
Agora, as próximas etapas são para o WordPress, o que é típico para ambos os cenários acima.
Em seguida, você precisa ir ao servidor onde instalou o WordPress e atualizar o arquivo wp-config.php. Isso ocorre porque normalmente não se configura o WordPress para ser executado em um proxy reverso.
Portanto, você deve atualizar o arquivo wp-config.php conforme abaixo:
$_SERVER['REQUEST_URI'] = str_replace("/wp-admin/", "/blog/wp-admin/", $_SERVER['REQUEST_URI']);
Em seguida, no mesmo arquivo, você atualiza as seguintes variáveis:
Nesse meio tempo, você pode atualizar os valores de configuração do banco de dados conforme abaixo:
UPDATE wp_options SET option_value = 'https://www.somedomain.com/blog' WHERE option_name IN('siteurl', 'home');
A próxima etapa é modificar o arquivo .htacess para que você possa reescrever os URLs corretamente:
Torna-se:
RewriteRule . /blog/index.php [L]
Depois de concluir todas as etapas acima, você precisa garantir que os links de postagem e de categoria estejam funcionando conforme o esperado. Para isso, você precisa fazer login com o URL do subdomínio antigo, como abaixo:
blog.somedomain.com/wp-login.php
Então, seria útil se você navegasse até "configurações" no painel principal e clicasse na guia "Geral".
No campo Endereço do site (URL), atualize conforme abaixo:
Depois de fazer isso, se você ainda estiver em dúvida se os URLs funcionarão corretamente, poderá instalar o plug-in "Better Search Replace". Ele atualizará todos os registros do seu banco de dados quando necessário.
Além disso, você também deve ter cuidado ao atualizar os canônicos e o robot.txt.
Depois de fazer isso, se você ainda estiver em dúvida se os URLs funcionarão corretamente, poderá instalar o plug-in "Better Search Replace". Ele atualizará todos os registros do seu banco de dados quando necessário.
Além disso, você também deve ter cuidado ao atualizar os canônicos e o robot.txt.
Agora você deve ter descoberto que o WordPress é altamente personalizável. Isso ocorre porque você pode usar o WordPress para hospedar somente a parte do blog do site separadamente, sem tocar no restante. Como você viu neste blog, o restante do site pode estar hospedado em diferentes plataformas que não oferecem suporte ao WordPress.
Portanto, incluir o blog no restante do site pode ser uma tarefa desafiadora. No entanto, você pode superá-los usando o proxies reverso.
Fique atento a outros artigos.