Cómo mantener un subdominio como un subdirectorio trucos CSS

Supongamos que tiene un sitio web creado en una plataforma que presenta un diseño y es accesible en example.comPero esta plataforma no se ocupa de los blogs. Así que piensas, "¿Qué pasaría si pudiera usar una plataforma de blog diferente y ponerla a disposición en example.com/blog? "

La mayoría de las personas le dirían que esto va en contra de la forma en que el DNS y los sitios web deberían funcionar y, en su lugar, usan un subdominio. Pero mantener su contenido en el dominio principal tiene beneficios que simplemente no obtenemos con los subdominios.

Hay una manera de servir dos plataformas diferentes en la misma URL. Y te mostraré la salsa secreta para que podamos hacerlo al final de este artículo. blog.example.com sirve como example.com/blog.

Por qué querrías hacer eso

Ya que estás aquí, probablemente ya sepas por qué este es un camino a seguir. Pero me gustaría asegurarme de que estás aquí por la razón principal por la que haces esto: SEO. ver estos 14 casos que muestran resultados positivos cuando las personas mueven sus subdominios a subdirectorios. Desea que su blog y su dominio compartan el valor de SEO. Ponerlo en un subdominio separaría un poco a los dos.

Esta fue mi razón y llegó a la fusión de dos plataformas, donde el dominio principal era WordPress y el subdominio era Drupal. Pero este tutorial no depende de la plataforma, funcionará con casi cualquier plataforma.

Sin embargo, el enfoque de Cloudflare que analizamos en este tutorial es incompatible con Shopify a menos que pague por el plan corporativo de Cloudflare. Esto se debe a que Shopify también usa Cloudflare y no nos permite representar el tráfico en su capa de precios gratuitos.

Paso 0 (Vista previa)

Antes de involucrarme, quiero explicar el alto nivel de lo que sucederá. En resumen, tendremos dos sitios web: nuestro principal (example.com) y subdominioblog.example.com). Uso un blog como ejemplo, pero en mi caso tuve que ejecutar Drupal con un tipo de contenido diferente. Pero el blog es el típico caso de uso.

Este enfoque se basa en el uso de Cloudflare para DNS y un poco más que proporcionará magia. Le diremos a Cloudflare que cuando alguien visite example.com/blogdeber:

interceptar esta solicitud (ya que example.com/blog en realidad no existe),
buscar otro dominio (blog.example.com/blog) entre bastidores y
entregar los resultados de este último paso al visitante enmascarado example.com/blog.

Bien, ¡vamos a sumergirnos en esto con más detalle!

Paso 1: Usa Cloudflare

usamos de nuevo Llamarada de la nube para DNS. Especificar el DNS de su dominio es el primer paso para comenzar.

El motivo de Cloudflare es que nos permite crear trabajadores que puede ejecutar un poco de código en cualquier momento cuando alguien visita ciertas URL (llamadas rutas que crearemos en el paso 3). Este código será responsable de cambiar los sitios web detrás de escena.

Cloudflare tiene una excelente guía para nos estamos preparando para empezarEl objetivo es dirigir su dominio, donde sea que esté registrado, a los servidores de nombres de Cloudflare y confirmar que Cloudflare está vinculado a su cuenta de Cloudflare.

Paso 2: Crear un trabajador

Este código será responsable de cambiar los sitios web detrás de escena. Ir a trabajadores y haga clic crear un servicio.

¡Preste atención al tiempo de CPU promedio! Este proceso se agrega para `.7ms` a la consulta (así que básicamente nada).

Asigne un nombre a su servicio, luego seleccione "Manipulador HTTP":

Hacer clic Creando un servicio y luego edición rápida.

Pegue el siguiente código y reemplace los nombres de dominio con los suyos propios en la línea 16:

// Listen for every request and respond with our function.
// Note, this will only run on the routes configured in Cloudflare.
addEventListener('fetch', function(event) {
  event.respondWith(handleRequest(event.request))
})

// Our function to handle the response.
async function handleRequest(request) {
  // Only GET requests work with this proxy.
  if (request.method !== 'GET')
  return MethodNotAllowed(request);
  // The URL that is being requested.
  const url = new URL(request.url);
  // Request "origin URL" aka the real blog instead of what was requested.
  // This switches out the absolute URL leaving the relative path unchanged. 
  const originUrl = url.toString().replace('https://example.com', 'https://blog.example.com');
  // The contents of the origin page.
  const originPage = await fetch(originUrl);
  // Give the response our origin page.
  const newResponse = new Response(originPage.body, originPage); return newResponse;
}

// Hey! GET requests only 
function MethodNotAllowed(request) {
  return new Response(`Method ${request.method} not allowed.`, {
    status: 405,
    headers: { 'Allow': 'GET' }
  })
}

Finalmente, haga clic en Preservación e implementación.

Paso 3: Agregar rutas

Ahora informemos a Cloudflare en qué URL (también conocidas como rutas) ejecutar este código. Vaya al sitio web de Cloudflare, luego haga clic en trabajadores.

Hay una sección de Trabajadores en la pantalla principal de Cloudflare donde editas el código, y luego hay una sección de Trabajadores en cada sitio web donde agregas rutas. Son dos lugares diferentes, y eso es confuso.

Primero, haga clic Añadir ruta:

Como agregamos un blog que tiene muchas páginas secundarias, usaremos https://example.com/blog*. Tenga en cuenta que el asterisco actúa como una tarjeta de coincidencia de reemplazo. Este código funcionará en la página del blog y en cualquier página que comience con blog.

Esto puede tener consecuencias no deseadas. Digamos, por ejemplo, que tiene una página que comienza con un "blog" pero que no es parte del blog real, p. https://example.com/blogging-servicesEsto será aceptado por esta regla.

A continuación, seleccione el trabajador en Servicio Menú desplegable.

Hemos hecho gran parte del trabajo, pero hay otras rutas que debemos agregar: CSS, JavaScript y otras rutas de archivo de las que depende el blog (a menos que todos los archivos estén alojados en una URL diferente, como un CDN). Una buena manera de encontrarlos es probar tu ruta y consultar la consola.

enfócate en los tuyos https://example.com/blog y asegúrese de que algo se está cargando. Parecerá confuso porque faltan archivos de tema Esto está bien por ahora, siempre y cuando no genere un error 404. Lo importante es abrir DevTools en su navegador, iniciar la consola y marcar cualquier URL roja que no pueda encontrar o cargar (generalmente 404 o 403 ) que forman parte de su dominio.

Los recursos en los recuadros naranjas son aquellos en los que debemos concentrarnos.

Querrá agregarlas como rutas... pero solo haga las carreteras principales. Entonces, si su URL roja es https://example.com/wp-content/themes/file1.cssentonces hazlo https://example.com/wp-content* También puede agregar una ruta secundaria si desea ser más específico, pero la idea es usar una ruta para capturar la mayoría de los archivos.

Después de agregar estas rutas, verifique su URL para ver si se parece a su subdominio. Si no, revisa los pasos anteriores. (Probablemente necesitará agregar más rutas).

Lo mejor es hacer un control de calidad yendo a algunas páginas y ver si falta algo. También te recomiendo que abras DevTools y busques tu subdominio (blog.example.com). Si esto ocurre, debe agregar rutas para apuntar a estos recursos o haga algo con su plataforma para dejar de mostrar estas URL. Por ejemplo, mi plataforma generaba una etiqueta canónica con mi subdominio, así que encontré un complemento para cambiar la URL canónica para que sea mi dominio principal.

Paso 4: La más secreta de las salsas (`noindex`)

Puedes ver que tenemos un problema. Nuestras URL están disponibles en dos URL diferentes. Sí, podemos usar canonical atributo para informar a Google qué URL es nuestra URL "principal", pero no dejemos que Google elija la correcta.

Primero, configura todo tu subdominio como noindex (La forma de hacerlo variará dependiendo de la plataforma). Luego, en Cloudflare Worker, agregaremos la siguiente línea de código que básicamente dice eliminar noindex al acceder a la URL actual a través de un servidor proxy.

newResponse.headers.delete("x-robots-tag");

La solución completa del código se proporciona al final de este artículo.

Paso 5: Cambiar el mapa del sitio

Lo último que debe hacer es cambiar el mapa del sitio del subdominio para que no use el subdominio en él. La forma en que esto variará dependerá de la plataforma, pero el objetivo es cambiar el dominio primario/absoluto/en su mapa del sitio para que imprima example.com/mypost) en cambio blog.exmaple.com/mypostAlgunos complementos y módulos permiten esto sin código personalizado.

¡Está! ¡La solución debe funcionar!

Límites

Esta magia de Cloudflare no está exenta de defectos. Por ejemplo, solo acepta GET solicitudes, lo que significa que solo podemos obtener cosas del servidor. No podemos POST esto es lo que usan los formularios. Entonces, si tiene que lograr que sus visitantes ingresen o envíen formularios, habrá más trabajo por hacer además de lo que ya hemos hecho. He discutido varias soluciones para esto en otro articulo.

Como se señaló anteriormente, otra limitación es que usar este enfoque en Shopify requiere una suscripción a los precios de Cloudflare Enterprise. Nuevamente, esto se debe a que Shopify también usa Cloudflare y limita el tráfico de proxy a sus otros planes.

También puede tener algunos problemas si intenta fusionar dos instancias en las mismas plataformas (por ejemplo, su dominio de nivel superior y su subdominio usan WordPress). Pero en ese caso, debería poder consolidar y usar una instancia de la plataforma.

Una solución completa

Aquí está el código en todo su esplendor:

// Listen for every request and respond with our function.
// Note, this will only run on the routes configured in Cloudflare.
addEventListener('fetch', function(event) {
  event.respondWith(handleRequest(event.request))
})
// Our function to handle the response.
async function handleRequest(request) {
  // Only GET requests work with this proxy.
  if (request.method !== 'GET') return MethodNotAllowed(request);
  // The URL that is being requested.
  const url = new URL(request.url);
  // Request "origin URL" aka the real blog instead of what was requested.
  // This switches out the absolute URL leaving the relative path unchanged. 
  const originUrl = url.toString().replace('https://example.com', 'https://blog.example.com');
  // The contents of the origin page.
  const originPage = await fetch(originUrl);
  // Give the response our origin page.
  const newResponse = new Response(originPage.body, originPage);
  // Remove "noindex" from the origin domain.
  newResponse.headers.delete("x-robots-tag");
  // Remove Cloudflare cache as it's meant for WordPress.
  // If you are using Cloudflare APO and your blog isn't WordPress, (but
  // your main domain is), then stop APO from running on your origin URL.
  // newResponse.headers.set("cf-edge-cache", "no-cache"); return newResponse; 
}
// Hey! GET requests only 
function MethodNotAllowed(request) {
  return new Response(`Method ${request.method} not allowed.`, {
    status: 405,
    headers:
    { 'Allow': 'GET' }
  })
}

Si necesita ayuda en el camino, lo invito a ponerse en contacto conmigo a través de mi sitio web. CreateToday.io o comprobar mi youtube para demostración en vídeo.

Deja una respuesta Cancelar la respuesta