How to Setup Blog in Subdirectory of Existing Static Website using Cloudflare Workers

In my case, since I want worker above to run whenever a client accessing “foreach.id/blog” or whatever routes inside “foreach.id/blog” subdirectory, I add two routes for the worker, which are: 1. *.foreach.id/blog , and 2. *.foreach.id/blog/*. The asterisks works as a wildcard to create dynamic pattern to match any URLs that has similar pattern.

To this point here, whenever I access “foreach.id/blog” from the browser, it will respond with similar response from “blog.foreach.id”, which means my blog will appear. The problem is that because the response is still raw and it doesn’t mean to be for “foreach.id/blog”, the functionalities inside that page won’t be completely functional. If you ready to make it all work well, let’s move to step 2.

Step 2

Here in this step, we want to make sure that all the content of the html file we get from the source site is applicable to its new site. I want all the anchor tags in my blog doesn’t direct it to blog.foreach.id/* but instead to foreach.id/blog/*, I want it when I share my blog in social media, it doesn’t share the source site but the new site, etc. 

So the main idea here in step 2 is to rewrite some essential tags (anchor, meta, image, etc) from source site’s HTML file to make it works with the new site. For this purpose, Cloudflare Workers original documentation has already provide the example which you can read here. To do this, we can edit the previously deployed worker before and make it to be something like this below.

const OLD_URL = "https://blog.foreach.id"
const NEW_URL = "https://foreach.id/blog"
async function handleRequest(req) {
  const res = await fetch(req)
  return rewriter.transform(res)
}
class AttributeRewriter {
  constructor(attributeName) {
    this.attributeName = attributeName
  }
  element(element) {
    const attribute = element.getAttribute(this.attributeName)
    if (attribute) {
      element.setAttribute(
        this.attributeName,
        attribute.replace(OLD_URL, NEW_URL)
      )
    }
  }
}
const rewriter = new HTMLRewriter()
  .on("a", new AttributeRewriter("href"))
  .on("img", new AttributeRewriter("src"))
  .on("link", new AttributeRewriter("href"))
  .on("meta", new AttributeRewriter("content"))
addEventListener("fetch", event => {
  let url = event.request.url.split("/blog")[1]
  event.respondWith(handleRequest(OLD_URL+url)
  .catch(err => new Response(err.toString(),{status:500})))
})

This code above is very similar to the original documentation of cloudflare workers to rewrite links, I just added some other tags to rewrite and some logic to parse the requester url to make this worker dynamic and applicable with the asterisks in the route. 

Here is what happened in the code above. Whenever the worker being requested (i.e. https://foreach.id/blog* accessed by a client), the worker will fetch HTML file from the source site (i.e. https://blog.foreach.id*), and then rewrite some of its tags’ attribute which contains “OLD_URL” and replace it with “NEW_URL”. Tags and their attribute that being affected here are:

1. href attribute from anchor tag (<a />)
2. src attribute from image tag (<img/>)
3. href attribute from link tag (<link/>)
4. content attribute from meta tag (<meta/>)

You can also append or prepend anything to every tags from the HTML source. For example, if you want to add Google Analytics script, you can append it to the head tag by using element.append inside “element” method in AttributeRewriter class above.

This step here is a little tricky so my code here maybe doesn’t completely works for you. You can write up more code to suit you better and you might need more code to modify response data or / and modify request data. There is a lot of factors that can influence the complexity of this step such as the blog template, CORS, etc. 

Anyway, at this point, you should be able to:

1. Access blog in your site’s subdirectory. 
2. Click any anchor tag and not redirected to the source site.
3. Share your blog and share url of the new site, not url of the source site.

Your blog is already placed in your site’s subdirectory, but there is still one thing to adjust.

Step 3

You want to move your whole blog in you main site’s subdirectory, you don’t want your source site to be accessible because it will hurt your newly-placed-blog popularity. I mentioned before that we will need our source site to be fully accessible, we need it for this step. Here in this step we are going to serve all request for the source site by redirecting it to the new site. To do this you need full access to your source site. And you can do it by simply use page rules or using cloudflare worker again. If you choose to use cloudflare worker, you’ll need to create new worker and then assign routes for it. You can see the original documentation for redirecting request here.

Here is the worker code for redirecting looks like for my project:

const base = "https://foreach.id/blog"
const statusCode = 301
async function handleRequest(request) {
  const url = new URL(request.url)
  const { pathname, search, hash } = url
  const destinationURL = base + pathname + search + hash
  return Response.redirect(destinationURL, statusCode)
}
addEventListener("fetch", async event => {
  event.respondWith(handleRequest(event.request))
})

After you save and deploy the worker, you’ll have to assign routes of which the worker will run, which is the source site. For me, I assign *blog.foreach.id and *blog.foreach.id/* for this worker. Those are the source site of my blog. After save, deploy, and assign routes, you can test if the worker works properly by accessing your blog’s source site and see when it redirects you to your new site.

That’s it !

After all those steps, your blog now will be under your main site’s subdirectory, and hopefully everything work well!

Simple Performance Comparison

At first I think this method will hurt my blog’s performance since it needs to rewrite the HTML file first before the worker deliver it. So I ran a little performance comparison between the source blog site and the new blog site using Lighthouse and the results are unpredictable. Here is the screenshots of both the audits of one article in my blog.

Lighthouse audit for source site (https://blog.foreach.id/*)

Lighthouse audit for new site (https://foreach.id/blog/*)

Seems weird to have the new site scores bigger in performance than its source site. It seems some factors affect it, but my point here is that, Cloudflare Worker is really fast. Because I thought the method will decrease my blog’s performance, but it’s not.

Conclusion

To increase your site’s traffic, authority, or SEO-related performance, sometimes you want to put your blog under your main site’s subdirectory. But there has been a lot of concern about its complexity especially if the static files are hosted in some static cloud storage. You can set it all up by using cloudflare workers to do this three main steps: 

1. Respond for request to your subdirectory with the response from the blog’s source site,
2. Rewrite some essential tags (anchor, meta, image, etc) from source site’s HTML file to make it works in subdirectory, 
3. Serve all request to the source site by redirecting it to the subdirectory. 

This method here has proven to be working for me to move my blog from here (source site) to here (blog in main site’s subdirectory). And there hasn’t been any performance issues resulted from this method either. All is working well.

Note If you find this article helpful, feel free to share it or give it a like. Or if you have some questions, advices, or concerns, please write it on the comment section. Thanks!