
A key part of ensuring a site's online visibility is making sure that good crawlers (e.g. Googlebot, Bingbot) aren't being blocked by rate limits or bot protections in your CDNs or other security systems.

Alongside a reliable regular expression to verify distinct user agents, it's important to maintain an up-to-date list of IP ranges that each crawler operates from. These ranges change frequently, so keeping track of them all can prove tricky.

Fortunately, this is becoming simpler thanks to a de-facto standard emerging, with the major crawlers publishing their IP prefixes in a common JSON format. For instance, here's a sample of what Google [provides](https://developers.google.com/static/search/apis/ipranges/googlebot.json) for Googlebot:

```json
{
  "creationTime": "2025-07-18T14:46:17.000000",
  "prefixes": [
    { "ipv6Prefix": "2001:4860:4801:10::/64" },
    { "ipv4Prefix": "192.178.4.0/27" }
    /** Truncated **/
  ]
}
```

These feeds can be periodically consumed by your security systems and/or tooling to generate a fresh allowlist and avoid good bots being blocked.

To help keep track of changes to these feeds, I've set up a [repo](https://github.com/searchtheoryio/ips/tree/main) which uses Simon Willison's [git scraping](https://simonwillison.net/2020/Oct/9/git-scraping/) technique to track any changes for each feed into the [./src/](https://github.com/searchtheoryio/ips/tree/main/src/) directory, plus generate [a combined feed](https://raw.githubusercontent.com/searchtheoryio/ips/refs/heads/main/dist/ips.json) for all sources.

Below is a list of the feeds being tracked at the time of writing:

| Vendor          | Source                                                                                                                               |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Google**      | [googlebot.json](https://developers.google.com/static/search/apis/ipranges/googlebot.json)                                           |
| **Google**      | [special-crawlers.json](https://developers.google.com/static/search/apis/ipranges/special-crawlers.json)                             |
| **Google**      | [user-triggered-fetchers.json](https://developers.google.com/static/search/apis/ipranges/user-triggered-fetchers.json)               |
| **Google**      | [user-triggered-fetchers-google.json](https://developers.google.com/static/search/apis/ipranges/user-triggered-fetchers-google.json) |
| **OpenAI**      | [searchbot.json](https://openai.com/searchbot.json)                                                                                  |
| **OpenAI**      | [chatgpt-user.json](https://openai.com/chatgpt-user.json)                                                                            |
| **OpenAI**      | [gptbot.json](https://openai.com/gptbot.json)                                                                                        |
| **Perplexity**  | [perplexitybot.json](https://www.perplexity.ai/perplexitybot.json)                                                                   |
| **Perplexity**  | [perplexity-user.json](https://www.perplexity.ai/perplexity-user.json)                                                               |
| **Microsoft**   | [bingbot.json](https://www.bing.com/toolbox/bingbot.json)                                                                            |
| **DuckDuckGo**  | [duckduckbot.json](https://duckduckgo.com/duckduckbot.json)                                                                          |
| **DuckDuckGo**  | [duckassistbot.json](https://duckduckgo.com/duckassistbot.json)                                                                      |
| **Apple**       | [applebot.json](https://search.developer.apple.com/applebot.json)                                                                    |
| **Mistral**     | [mistralai-user-ips.json](https://mistral.ai/mistralai-user-ips.json)                                                                |
| **CommonCrawl** | [ccbot.json](https://index.commoncrawl.org/ccbot.json)                                                                               |

You can view the repository using the link below:

<div className="mt-6">
  <Button size="lg" asChild>
    <Link href="https://github.com/searchtheoryio/ips">View Repository</Link>
  </Button>
</div>

If you have any questions, please feel free to [reach out](/c)!


Tracking published crawler IP ranges


A few years ago I was involved in the migration of a large website over to a new CMS, which required finding a way to redirect 100k+ legacy URLs into their new equivalent.

We found a solution for this using a combination of PHP scripts and SQL lookups, however the task of updating references to old URLs within the site content is ongoing to this day. This, combined with subsequent site architecture changes, has meant that a large number of redirect chains now exist. For instance…

```
/node/12345                 301 to /blog/article-one/
/blog/article-one/          301 to /blog/category/article-one/
/blog/category/article-one/ 301 to /landing-page/
/landing-page/              200
```

In an ideal world each hop would redirect straight to /landing-page/ - saving the client round-trips to the server, and the server the overhead of additional requests.

Whilst it's good practice, staying on top of this is't always possible. Tech constraints and higher priorities can cause chains to build up over time to the point where tackling it is a huge task requiring time and effort which is hard to justify.

Solving this issue seemed like a fun challenge and a perfect application for a technology like Cloudflare Workers, so I set to work building a proof of concept which I've dubbed "three-o-none".

## How it works

At a top-level, Cloudflare allows you to route your website through their global network of servers. This allows them to serve as a CDN, prevent DDoS attacks, carry out performance optimisations and apply various other security measures.

One of their features is [Workers](https://workers.cloudflare.com/), which allows developers to write code which runs on Cloudflare's servers and can modify requests on their way to a web server, and responses on the way back. This allows us to build platforms like [Spark](https://spark.strategiq.co/) and experiments like [this proof of concept petitions platform](https://simon-thompson.me/posts/100-uptime-democracy-replicating-the-hoc-petition-site-on-the-edge/).

three-o-none is entirely Workers-based, meaning that the only requirement is that a site is routed through Cloudflare.

### Mapping 301 chains

The first step is to build up a map of all of the redirects on a website. Thanks to it's position as a middleman, three-o-none watches for server responses with a 301 status code and keeps track of them using [Workers KV](https://www.cloudflare.com/products/workers-kv/).

A benefit to this approach is that no redirect data needs to be manually loaded in, and new redirects will be tracked automatically the first time they're requested.

### Rewriting 301 responses

Once it's built up a knowledge of redirects, three-o-none begins to intercept responses with HTTP 301 status codes as they come back from the server.

It then inspects the Location header (which says where the redirect should go), and looks it up in the list of redirects it's tracked. It then looks at the location of that redirect, and follows the chain as far as it can.

If the final location of that chain doesn't match the location sent from the server, three-o-none will rewrite the response Location header to point to the final URL before sending it back to the end user.

### Rewriting internal links

With this knowledge of redirects, three-o-none can also automatically rewrite the target (href attributes) of internal links (`<a>` tags) which point to URLs which redirect.

This means that when a user clicks (or a bot follows) a link, they'll go directly to the final URL rather than bouncing through redirects (flattened or not).

### Dashboard

Once installed, all of this functionality is manageable via a simple dashboard, made available on the domain at `/seo-cgi/redirects/`.

The dashboard allows the Redirect Flattening and Link Rewriting features to be quickly toggled off, and provides a reference table of all redirects which have been detected, where they originally pointed, and where they have been flattened to.

<Image src="/images/p/solving-301-redirect-chains-automatically-on-the-edge-dashboard-overview.png" alt="Dashboard Overview" width={1948} height={1653} />

Additionally, when the dashboard is first loaded, it will prompt you to set a password to help keep it safe from prying eyes.

<Image src="/images/p/solving-301-redirect-chains-automatically-on-the-edge-dashboard-security.png" alt="Dashboard Security" width={1988} height={397} />

### Using three-o-none

I'm currently open to working with people to help them try out three-o-none whilst I prepare it for general availability (it'll be open sourced ASAP).

If you think three-o-none may be able to help your website, please click the button below to register your interest, and I'll be in touch as soon as possible!

<div className="mt-6">
  <Button size="lg" asChild>
    <Link href="https://docs.google.com/forms/d/e/1FAIpQLScflSEOM_q5NKCEePlfDA6_na4aIgGPbDA87ceKrob_Oghdqw/viewform">
      Register interest
    </Link>
  </Button>
</div>

If you have any questions about three-o-none or have a tricky SEO issue you think
Edge SEO might be able to solve, please also [get in touch](/c) - I'd love to chat!


three-o-none: Fixing redirect chains with Cloudflare Workers

Releasing gtrends.app - A Google Trends Connector for Data Studio


Something which caught my eye recently was a petition on the [UK Government Petitions Site](https://petition.parliament.uk/), which went viral and saw 4M+ signatures in a few days. However, during this time the site went down repeatedly - quite understandable due to the sudden high demand (the [highest they've ever dealt with](https://twitter.com/HoCpetitions/status/1108711303865139202), peaking between [80K-100K simultaneous users](https://twitter.com/HoCpetitions/status/1108711030736199686)).

This got me thinking; with the rise of Edge Computing, how feasible would it be to run a service like this entirely "on the Edge" and thus mitigate the risks of downtime due to traffic spikes / resource limitations? As a bit of weekend fun, and to serve as an example when I'm explaining "the Edge" to friends and colleagues, I've put together a proof of concept.

## The objectives

<Image src="/images/p/100-uptime-democracy-replicating-the-hoc-petition-site-on-the-edge-hoc-petitions.png" alt="The UK House of Commons Petition Website" width={1024} height={639} />

The actual service itself has quite a few features; creating and searching petitions, for instance. We won't focus on these for now, and instead we'll look at the parts of the application which would have been seeing the highest throughput; namely viewing and signing petitions.

Our proof of concept app should achieve the following;

- List available petitions
- Allow viewing of a petition page, with an up-to-date signature count
- Allow signing of a petition, with one submission per unique email

We'll also be building it with the following considerations in mind;

- The petition in question has 4M+ signatures. We'll need to support this amount of data (ideally more, of course!).
- The petition saw a rate of ~2K signatures per minute, which is roughly 33 every second. We'll need to support this many writes-per-second.

Now, before we get into the technical side of things...

## What is "The Edge"?

The "Edge" is an iteration on "serverless computing" - a model whereby applications use a cloud provider to manage their infrastructure. Despite the name "serverless", servers are still involved - it's instead referring to the idea that the developer does not self-provision servers / virtual machines for the code to run on.

The "Edge" element comes into play with things like Cloudflare Workers, which allow you to deploy your code and run it on the "Edge" - the "Edge" here being their network of 165+ data centers around the world.

In essence, this means we can deploy code without the need to spin up, manage or scale any servers, which provides an exciting prospect in the face of issues such as the traffic spikes to the Petitions site. If they could run on the Edge, they'd have no need to scale servers during peak load.

## Building a proof of concept

As I'm most familiar with their stack through my work on [Spark](https://spark.strategiq.co/), I chose to use [Cloudflare Workers](https://developers.cloudflare.com/workers/about/how-workers-work/) for the computation side of things, paired with [Workers KV](https://developers.cloudflare.com/workers/kv/) for persistent storage.

I chose Workers KV as I wanted to build the entire thing on one provider, but in reality it may be suitable to use an alternate data store (i.e. Google's [Cloud Firestore](https://firebase.google.com/docs/firestore/)) to support querying / searching, something a key-value store won't excel at.

The application itself is pretty simple; it's written in TypeScript, compiled and bundled using Webpack (courtesy of the process described in [this Cloudflare post](https://blog.cloudflare.com/using-webpack-to-bundle-workers/)), and uses request routing logic heavily inspired by workerrouter. Local testing was made possible with [cloudflare-worker-local](https://github.com/ejcx/workerrouter), and I combined this with periodic pushes up to the [Workers Playground](https://cloudflareworkers.com/) for testing via the [workers-preview](https://www.npmjs.com/package/workers-preview) module.

The list of available petitions is stored as JSON in the KV store, and is read frequently by the app. Whilst Workers KV does allow "Unlimited" reads per-second per-key, this is optimised further by caching the result in memory so it can persist between requests during high traffic periods as described in the documentation here, and thus improves performance.

Petition signatures are stored in the KV store too, with a key of the format `signature-{PETITIONID}-{HASHOFEMAIL}` which allows quick checks to see whether an email has already been registered against a petition.

One challenge was around showing a count of signatures for petitions. With an estimated throughput of 33 signatures per-second, we'd far exceed the one-write per-second per-key limit imposed by Workers KV if we were to try and maintain some kind of counter in the main petitions list. As such, when a signature is added, the app checks whether the petition has had it's signatures counted within the past 30s and - if not - counts the number of stored values with a key beginning with `signature-{PETITIONID}` which have been added since the last count.

<Image src="/images/p/100-uptime-democracy-replicating-the-hoc-petition-site-on-the-edge-edgepetitions-1.png" alt="Screenshot of the EdgePetitions proof of concept app" width={1372} height={1142} />

Overall, once deployed to Cloudflare's Edge, we're left with a fast (~150ms load time) app, which can handle insane amounts of traffic without us needing to intervene or manage any servers. Whether we're serving 10 requests or 10 million, our code will continue to run exactly the same - without any resource-related downtime.

You can [view the source code for this project on GitHub](https://github.com/SimonJThompson/edge-petitions).

## Running the service

Another great thing about serverless (and Cloudflare Workers in particular) is that you typically only pay for what you use. In our case, we'd be paying per-request, with Workers having the first 10M requests included in a $5 baseline cost, and then it's $0.50 per million requests thereafter.

I haven't seen any stats around the exact traffic to the official Petitions site, but to illustrate how low the costs are here I've estimated some figures below.

<Image src="/images/p/100-uptime-democracy-replicating-the-hoc-petition-site-on-the-edge-costs.png" alt="Screenshot of expected costs for running the HoC Petitions app on the Edge" width={586} height={419} />

Although these are very rough numbers, what we're able to see is that an Edge-based app like this could manage a sudden spike of 10M signatures, serving 30 million HTTP requests, for only $15. During non-peak periods, we'd likely drop down to a baseline cost of $5/m, so we're not wasting any money on servers which are doing nothing.

This could potentially be optimised even further via the use of Cloudflare's additional features; for instance page-level caching for GET requests, or custom firewall rules to block bad actors.

## Summary

Overall, this was a fun weekend project to try out some new tech, and hopefully demonstrate some of the benefits of serverless.

Whilst I understand that there are regulations and such which might prohibit this example from being implemented in practice, this hopefully shows that applications can be designed to successfully run "on the Edge" to help them weather the storm of going viral.

## Additional notes

On the off-chance that somebody from Cloudflare does wind up reading this post, there are a few things which I feel would make building with Workers even better.

### Expose KV NAMESPACE.list() in the Worker API

Part of this proof-of-concept uses the [/:namespace_id/keys API endpoint](https://developers.cloudflare.com/workers/kv/api/#list-keys), however this doesn't seem to be exposed through the "in Worker" API, which meant I needed to call the API directly. I'm guessing there might be performance reasons for this, but if not then it'd be super handy.

### Support environment variables for configuration

I don't believe Workers currently supports any kind of environment variables (besides storing that config within a KV store itself, I guess). This meant that I needed to code the API Credentials directly within the worker code, which doesn't feel ideal (especially when combined with wanting to push up to the Workers Preview site, which is essentially public).

### Allow scoped API tokens

This is something which people have already raised over on the forums, so might already be in development, but scoped API credentials would be a great improvement over the current account-wide API tokens.


100% Uptime Democracy

Introducing Spark - A meta CMS for SEO teams

Does the number of .htaccess rules impact performance and scalability?


Imagine that, instead of crawling the whole internet to discover new domains, you were just told about them as soon as they launched in near-realtime. Even better; imagine that this was available to anybody, not just the huge tech companies. What could the possibilities be, and what could be built?

A while back now, I posted a tweet with a musing I'd had after reading up on the [Certificate Transparency](https://certificate-transparency.org/) project. I was wondering if the underlying technologies - which are designed to allow for the auditing and monitoring of SSL certificate issuance - could serve a wider purpose in the area of web crawling, and whether it (or something similar) could trigger a shift in the way that crawlers operate in the distant future. In this post, I wanted to share my line of thinking.

Before we start to look at Certificate Transparency itself, let's recap on the various methods by which an existing crawler (be it for a search engine, or any other purpose) might discover previously-unseen domains to process:

1. **Standard Crawling**<br/>
   Relies on sites being linked to in order to discover them, and can be resource intensive (you may need to crawl an entire site just to discover one new domain).
2. **Manual Submission**<br/>
   Relies on people manually submitting their sites to you.
3. **Parsing TLD Zone files**<br/>
   Only discovers the apex domain - you'll be missing any subdomains.

Each of these has their own merits and drawbacks, but one thing in common is this; you need to somehow go looking for new sites to crawl. This is where Certificate Transparency comes in…

## What is Certificate Transparency?

Certificate Transparency is a framework designed to allow monitoring and auditing of SSL Certificate issuance. When a trusted Certificate Authority (such as [Let's Encrypt](https://letsencrypt.org/) or [Cloudflare](https://www.cloudflare.com/)) issues a new certificate, they push an entry with it's details to a number of cryptographically-verified [public logs](https://www.gstatic.com/ct/log_list/log_list.json) which can then be read by any number of consumers. An example consumer is the [crt.sh](https://crt.sh/?q=simon-thompson.me) tool, which allows us to view all of the certificates generated for this domain (simon-thompson.me).

<Image src="/images/p/moving-to-a-known-web-using-certificate-transparency-to-crawl-the-internet-crtsh.png" alt="Screenshot of the crt.sh UI" width={1024} height={413} />

Needless to say, this additional layer of transparency is a good thing for security on the web. It allows site owners to detect mis-issued certificates which could be impersonating them, and it allows rogue CA's to be identified easily. If you'd like to read up a bit more on CT itself or want more technical details, I recommend reading [Scott Helme's introductory post](https://scotthelme.co.uk/certificate-transparency-an-introduction/), plus the [official site](https://www.certificate-transparency.org/) itself.

Over the past few years, CT has increasingly become a requirement. For instance, Chrome now [requires](https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/sz_3W_xKBNY/6jq2ghJXBAAJ) that an SSL certificate is logged via CT otherwise it simply won't trust it - a move which has encouraged CA's to adopt the technology. When you combine that with the increasing shift to have HTTPS as the default (e.g. [Chrome's UI changes](https://www.theverge.com/2018/2/8/16991254/chrome-not-secure-marked-http-encryption-ssl) and Google's incorporation of [HTTPS as a ranking signal](https://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html)), we're increasingly headed towards a web where the majority of the public-facing web is going to be using an SSL Certificate and, by extension, getting logged into a CT log (all good things, might I add).

## Use Cases & Caveats

So we've got a near-realtime stream of domains, but what can we actually use it for? Some examples I can think of are;

1. **Search Engines**<br/>
   Albeit more limited by the caveats which I'll detail momentarily, it's possible that search engines could choose to use Certificate Transparency logs as a source of domains for their crawlers.
2. **Phishing Detection**<br/>
   [Facebook](https://www.facebook.com/notes/protect-the-graph/detecting-phishing-domains-using-certificate-transparency/2037453483161459/) (and [others](https://github.com/6IX7ine/certstreamcatcher)) have done some work in this area already, but it's possible to rapidly detect possible phishing attacks.
3. **Vulnerability Analysis**<br/>
   Given that most people won't be aware that the certificates they generate are being logged, a large amount of staging, development and otherwise hidden environments can be exposed.<br/><br/>
   As an aside, if you're hoping to protect against this you should look to implement security methods - such as HTTP basic auth for staging sites - before or as soon after generating an SSL certificate as possible.<br/><br/>
   Assume that it will be public knowledge and poked by vulnerability scanners within a matter of hours at most. There are also some options around [redaction in CT](https://wiki.mozilla.org/CA/CT_Redaction#Logging_Reveals_Commercially_Sensitive_Information) which you may wish to review.

Of course, this list is non-exhaustive. The thing which interests me about all of this though, is that certificate transparency essentially democratises the list of sites on the web so people can build whatever they want on top of it.

As always, there are some caveats to the data available:

1. By definition, you're only going to discover sites which have had a certificate generated and are on HTTPS. This will be an increasingly large portion of the web as time goes by, but you'll still be missing non-secure sites and might need to detect them through other means.
2. A lot of these domains are probably not designed to be public. For example, a huge amount of certs are for things like webmail / staging / control panel subdomains so, depending on your use case, aren't worth pursuing. You could filter these out, of course.

## How to access the logs

Now, you may be wondering how easy it is (or isn't) to tap into the logs to try this out for yourself. It is possible to directly read them, however for the scope of this blog post and experimenting there's an easier (and currently free) option - namely [certstream](https://certstream.calidog.io/) - which abstracts away the work of parsing the huge logs and turns it into one simple stream.

Using their code samples, you can very quickly get something up and running which looks like the below.

<Image src="/images/p/moving-to-a-known-web-using-certificate-transparency-to-crawl-the-internet-certstream.gif" alt="Animated GIF of certs from the certstream API" width={749} height={298} />

## Summary

I'm not as naive as to believe that things will change overnight, especially given that a large portion of the web (including some major sites) is still not on HTTPS, but I can't help but feel that we'll see a move towards a "known web" where a large amount of domains can be discovered quite easily with less overhead than required today.

This could mean sites being picked up and crawled more quickly, vulnerabilities being discovered before a site's even made public, and information being disclosed that was assumed to be private (although, if you're relying on security by obscurity, that's probably not ideal anyway!).

Overall though, I'm excited to see what unexpected use cases come out as a side effect of Certificate Transparency as a technology.


Moving to a "Known Web"


<Alert>
  <AlertTitle>Heads up!</AlertTitle>
  <AlertDescription>
    The Workers platform has matured significantly since I wrote this post way
    back in 2018. If you're looking into DOM manipulation today, I'd recommend
    checking out their native [HTMLRewriter
    API]([https://developers.cloudflare.com/workers/runtime-apis/html-rewriter](HTMLRewriter
    API)) which offers a simple, performant, stream-based interface for
    modifying the DOM.
  </AlertDescription>
</Alert>

I've recently been trying out [Cloudflare Workers](https://blog.cloudflare.com/introducing-cloudflare-workers/) as part of another write-up which I'll be sharing soon, and I'm really excited about their potential. For those who aren't familiar with them, Cloudflare Workers allow you to write custom JavaScript code to run "on the edge" (i.e. in Cloudflare's data centres) which can modify a user's request on it's way to your origin server, or the response on the way back.

This is pretty exciting, as it opens up a range of options across the board in the realms of security, performance and customisation (among others).

## The problem

The particular use-case I'm looking at involves lots of DOM manipulation - i.e. changing page content - something which is quite tricky with Cloudflare Workers currently as your only options are string manipulation and regex, which can get unwieldy very quickly. Ideally we'd be able to use the same tools that we use with JavaScript in a browser - like `document.querySelectorAll` to find elements matching a CSS selector - but Workers aren't Browsers, so unfortunately these methods aren't available to us.

After a number of tests I emailed to get the opinion of the Cloudflare Developer Help team, who let me know that they're planning improvements in this area in the near future, but in the meantime they were aware of another user who had managed to incorporate some DOM functionality into their Worker by [browserifying](http://browserify.org/) the Node.js [dom-parser](https://www.npmjs.com/package/dom-parser) module and including it in their Worker, so that might be an option to investigate in the meantime.

I tinkered with this and got it working pretty quickly, but it got me thinking; this is a good option for getting data out of the page, but what if we could include something like jQuery in a Cloudflare worker? This would reduce the complexity of DOM manipulation massively, potentially even for non-developers, and allow us to easily modify the response before sending it to the client.

## The solution

It turns out, the [cheerio module](https://github.com/cheeriojs/cheerio) for Node.js provides exactly what we need - a server-side implementation of jQuery.

After a few hours of testing and tweaking, I've managed to get a proof of concept working which embeds Cheerio (jQuery) into a Cloudflare Worker. If you'd like to give it a go yourself, you can play around with the code in the [Playground I've put together](https://cloudflareworkers.com/#5d38b2ef6a678f6aa94f9816c8d75ccb:https://tutorial.cloudflareworkers.com) (alternatively the source is available in [this gist](https://gist.githubusercontent.com/SimonJThompson/eccfd0bc6ba9876047c81d602679414f/raw/48a89531d1bc0eac0a1b33923f97f4a4ce64a7cd/cloudflare-jquery.js)). Feel free to make use of either in your own projects!

In the example below, I'm using jQuery to modify the response from the server and change the content of all h1 tags to be `¯*(ツ)*/¯`

<Image src="/images/p/simple-dom-manipulation-via-jquery-in-cloudflare-workers-cheerio-example-1.jpg" alt="Screenshot of h1 tags being modified by a Cloudflare Worker" width={1920} height={1080} />

You can also apply CSS styles, as seen in the example below (note that all of the changes happen "on the edge" before the response is sent to the client - no Javascript is running in the client / browser);

<Image src="/images/p/simple-dom-manipulation-via-jquery-in-cloudflare-workers-cheerio-example-2.png" alt="Screenshot of CSS being applied by a Cloudflare Worker" width={1920} height={1080} />

The possibilities here are huge!

## Bundling npm modules

If you're a developer interested in how to bundle NPM modules into a Worker script, the steps are roughly as follows;

1. Install [Browserify](https://browserify.org/) globally
2. Create a new node project with `npm init`, and `npm install` the module(s) you need
3. Create a file main.js, and add a `require('module')` for each module
4. Run `browserify main.js -o bundle.js`
5. Look through bundle.js and find `function(require,module,exports){...}` - your code will go inside of this function. Drop the sample code from the [Playground site](https://cloudflareworkers.com/) in that function, paste it back into the Playground, and check the console to see if you get any errors.

As an additional step, you can minify the output of Step 4 by using an ES6-compatible minifier (like [UglifyJS](https://skalman.github.io/UglifyJS-online/) Online) which will give you tidier code to work with.

I did find that this required a bit of tweaking of minifier settings to get it working correctly, so if you're struggling - [drop me a message](/c) and I'm happy to chat!


Writing

Tracking published crawler IP ranges

three-o-none: Fixing redirect chains with Cloudflare Workers

Releasing gtrends.app - A Google Trends Connector for Data Studio

100% Uptime Democracy

Introducing Spark - A meta CMS for SEO teams

Does the number of .htaccess rules impact performance and scalability?

Moving to a "Known Web"

Simple DOM Manipulation via jQuery in Cloudflare Workers

How to View Referring Twitter Users as a Custom Dimension in Google Analytics

Is Rank Tracking Messing with Our Google Search Console Metrics?

0% Stability in SERPs — An Experiment in Hourly Rank Tracking