¿Alguna vez se ha encontrado en una situación en la que necesita tener un blog en el sitio web de su empresa que no funciona con WordPress? Seguro que la mayoría de vosotros os habéis enfrentado a este tipo de situaciones. En este artículo, descubrirás una forma de conseguirlo sin comprometer el SEO. Antes de sumergirnos en ello, vamos a explorar cómo el
¿Alguna vez se ha encontrado en una situación en la que necesita tener un blog en el sitio web de su empresa que no funciona con WordPress? Estoy seguro de que la mayoría de ustedes se han enfrentado a este tipo de situaciones.
En este artículo, descubrirá una forma de conseguirlo sin comprometer el SEO.
Antes de entrar en materia, veamos cómo las organizaciones e instituciones utilizan el alojamiento del blog separado del sitio web principal.
Muchas grandes empresas tienen sistemas informáticos complicados, lo que dificulta a sus departamentos internos buscar fuera del ámbito de sus sistemas internos. Tomemos, por ejemplo, el deseo del departamento de marketing de contenidos de crear un blog para ilustrar a su audiencia. Sin embargo, la disposición actual hace imposible la creación de un blog, por ejemplo, en el alojamiento de WordPress.
Por otro lado, las empresas pueden utilizar el ".NET Framework" para sus aplicaciones web, y otras empresas se muestran reticentes a utilizar frameworks de código abierto.
Cuando necesites alojar un blog en cualquiera de los supuestos anteriores, no te quedará más remedio que pensar en un servidor alternativo para alojarlo. Este servidor es, por tanto, ajeno al servidor donde tienes alojado tu sitio web. Veamos algunas de estas opciones y el impacto que tendrían, ¿te parece?
Por ejemplo, si su sitio web principal tiene una URL de www.myorganization.com, los profesionales más competentes técnicamente del pasado se inclinarían por instalar el blog de WordPress comprando un subdominio del dominio principal. Como ejemplo en esta situación, sería en ourblog.myoraginzation.com.
En otros tiempos, esta solución sería perfecta. Sin embargo, en la actualidad, cuando tu objetivo es generar una cantidad considerable de tráfico a tu blog, necesitas considerar también los aspectos SEO (Search Engine Optimization). Lo veremos en la siguiente sección.
La razón principal por la que los propietarios de sitios compran subdominios es para tener contenido separado basado en varios productos para su marca. Aunque también puede haber otras razones, como un sitio web separado para móviles y dirigir el tráfico, la razón fundamental radica en el contenido y la expansión de su marca basada en varios nichos.
Por ejemplo, Wikipedia tiene subdominios para separar el contenido en función de varios idiomas, como fr.wikipedia.com o es.wikipedia.com.
NPR, una popular cadena de radio, es otro ejemplo en el que se centran al 100% en sus noticias y contenidos. Sin embargo, también tienen un subdominio, https://shop.npr.org/, que se centra principalmente en el merchandising.
Por lo tanto, en los casos mencionados anteriormente, tiene sentido tener un subdominio. Pero, ¿y en el caso de los blogs?
Pues bien, los motores de búsqueda consideran los subdominios como sitios web independientes. Esto implica que los motores de búsqueda tienen que rastrear e indexar cada subdominio por separado. Además, los backlinks hacia el dominio principal no se comparten con sus subdominios. Por lo tanto, construir el page rank para un subdominio es casi tan difícil como para el dominio principal.
Así que sería de ayuda tener subdominios en circunstancias en las que tenga sentido hacerlo. Por lo tanto, una opción ideal en los blogs sería tener el blog como un subdirectorio en su sitio principal.
Sin embargo, como he mencionado anteriormente, ¿cómo puede hacerlo en circunstancias en las que opera su sitio líder y cuando lo calienta en una plataforma diferente que no admite el alojamiento de WordPress?
Para eso precisamente sirven los proxies inversos, de los que le ofreceremos una visión general en la siguiente sección.
Entender el concepto de proxy inverso sería más fácil si supieras lo que hace un proxy directo.
Proxy de reenvío - Un proxy de reenvío reenvía todas las solicitudes entrantes de todos los nodos de la LAN (red de área local) al servidor pertinente al que debe ir la solicitud. El servidor de destino no tiene ni idea del origen de la solicitud y envía la respuesta al cliente que inició la solicitud a través del proxy de reenvío. El siguiente diagrama lo ilustra
Proxy inverso: Por el contrario, un Proxy Inverso se sitúa delante de los servidores y envía una petición al servidor correcto cuando el cliente inicia una petición. Entonces, cuando el servidor apropiado devuelve la respuesta, el proxy inverso devuelve la respuesta al dispositivo cliente. Al dispositivo cliente le parecerá que el servidor proxy inverso ha procesado todas las peticiones. Los Proxies Inversos son ideales en situaciones donde la misma porción de una aplicación web es escalada en muchos servidores diferentes.
Para obtener más información sobre los proxies inverso y directo, consulte este artículo.
Del mismo modo, puede utilizar un Proxy Inverso para dirigir el tráfico al servidor donde tiene alojado el blog de WordPress. Por otro lado, el Proxy Inverso dirigirá el tráfico ajeno al blog al servidor correspondiente. Sé que es más fácil decirlo que hacerlo. Así que vamos a demostrar con un ejemplo.
Supongamos que, como se muestra en el diagrama siguiente, su sitio web https://www.somedomain.com está alojado en un servidor web que no admite WordPress. Sin embargo, su equipo de marketing de contenidos se muere por tener un blog. Así que teniendo en cuenta todos los hechos SEO mencionados anteriormente, su equipo de desarrollo web no tiene más remedio que instalar el blog en el directorio "blog". Por lo tanto, el blog, URL aparecería como https://www.somedoamin.com/blog.
Dado que el sitio web principal no es compatible con WordPress, estos son los pasos que debe seguir su equipo de desarrollo web:
<?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>
En las dos líneas siguientes, "blog.somedomain.com" debe sustituirse por el subdominio en el que se encuentra su blog:
<rule name="blog.somedomain.com" stopProcessing="true">
<add input="{HTTP_HOST}" pattern="^blog.somedomain.com$" />
A continuación, en estas dos líneas, puede sustituir la carpeta "blog" si le ha dado un nombre diferente:
<add input="{PATH_INFO}" pattern="^/blog/" negate="true" />
<action type="Rewrite" url="\blog\{R:0}" />
En el último paso, aunque hayamos utilizado un subdominio, no afectará al SEO ya que el tráfico se generará hacia la carpeta del blog del sitio web principal. Por lo tanto, la redirección al subdominio es un proceso interno que no afectará al SEO.
Las circunstancias discutidas arriba son cuando usted está ejecutando un servidor que no soporta PHP. Sin embargo, si se encuentra con un escenario en el que su sitio principal está ejecutando PHP o Drupal, por ejemplo, pero desea tener un sitio diferente para el blog en el mismo dominio, es necesario configurar el proxy inverso de acuerdo con los siguientes pasos.
Pero antes, tienes que asegurarte de que tienes dos sitios en funcionamiento. Uno es https://www.somedomain.com, y el otro es con WordPress instalado con subdominio,https://blog.somedomain.com.
En primer lugar, tienes que abrir el terminal del servidor Apache a través de SSH. Luego necesitas habilitar el módulo proxy de Apache usando este comando:
sudo a2enmod proxy proxy_http ssl
Este comando reiniciará Apache en la mayoría de las ocasiones para recargar las nuevas directivas que haya definido anteriormente:
El siguiente paso es el que estabas esperando. Se trata de crear el proxy inverso editando el archivo de host virtual del servidor.
<VirtualHost *>
DocumentRoot /var/www/app/public
SSLProxyEngine On ProxyRequests off
ProxyPass /blog http://blog.somedomain.com
ProxyPassReverse /blog http://blog.somedomain.com
</VirtualHost>
Dos puntos vitales a tener en cuenta aquí son:
Ahora los siguientes pasos son para WordPress, que es típico para los dos escenarios anteriores.
A continuación, debe ir al servidor donde ha instalado WordPress y actualizar el archivo wp-config.php. Esto se debe a que no se suele configurar WordPress para que se ejecute en un proxy inverso.
Así que tienes que actualizar el archivo wp-config.php como a continuación:
$_SERVER['REQUEST_URI'] = str_replace("/wp-admin/", "/blog/wp-admin/", $_SERVER['REQUEST_URI']);
A continuación, en el mismo archivo, actualiza las siguientes variables:
Mientras tanto, puede actualizar los valores de configuración de la base de datos como se indica a continuación:
UPDATE wp_options SET option_value = 'https://www.somedomain.com/blog' WHERE option_name IN('siteurl', 'home');
El siguiente paso es modificar el archivo .htacess para poder reescribir las URL correctamente:
Se convierte:
RewriteRule . /blog/index.php [L]
Después de completar todos los pasos anteriores, es necesario asegurarse de que el post y los enlaces de categoría están trabajando como se esperaba. Para ello, es necesario iniciar sesión con la URL del subdominio de edad como a continuación:
blog.somedomain.com/wp-login.php
Entonces sería de ayuda si navegaras a "ajustes" desde el panel principal y luego hicieras clic en la pestaña "General".
En el campo Dirección del sitio (URL) actualice como se indica a continuación:
Una vez hecho esto, si aún tiene dudas sobre si las URL funcionarán correctamente, puede instalar el complemento "Better Search Replace". Actualizará todos los registros de tu base de datos cuando sea necesario.
Además, también debe tener cuidado con la actualización de canonicals y robot.txt.
Una vez hecho esto, si aún tiene dudas sobre si las URL funcionarán correctamente, puede instalar el complemento "Better Search Replace". Actualizará todos los registros de tu base de datos cuando sea necesario.
Además, también debe tener cuidado con la actualización de canonicals y robot.txt.
Ahora puede que hayas descubierto que WordPress es altamente personalizable. Esto se debe a que puedes utilizar WordPress para alojar sólo la parte del blog del sitio web por separado sin tocar el resto. Como has visto a través de este blog, el resto del sitio web puede estar alojado en diferentes plataformas que no soportan WordPress.
Por lo tanto, incluir el blog en el resto del sitio web puede ser una tarea difícil. Sin embargo, puedes superarlos utilizando proxies inversos.
Esté atento a nuevos artículos.