How a route works
A Workers route matches an incoming URL pattern and invokes an already deployed Worker before the request reaches an origin. The route does not contain the Worker code or its secrets. The hostname must be proxied through Cloudflare for a route to receive traffic.
Choose a precise pattern
Start with a staging hostname or a narrow path such as api.example.test/v1/*. A broad pattern such as example.test/* can intercept the whole site. More specific overlapping routes take precedence, so inventory existing patterns before adding another.
Prepare the Worker
Deploy and test the Worker independently, confirm its bindings and failure behaviour, and decide whether it should call the origin with fetch(). Never place credentials in a route or public response. Keep a known-good Worker version available.
Verify matching and fall-through
Test a matching URL, a neighbouring non-matching URL, query strings, redirects and an origin failure. Confirm response status, headers, cache behaviour and application logs. A route that saves successfully can still call the wrong script or shadow another route.
Prevent loops
A Worker that fetches a URL covered by its own route can recursively invoke itself. Use the incoming Request correctly for origin pass-through and avoid fetching a public URL that resolves back through the same route unless the design explicitly prevents recursion.
Rollback
Disable or remove the new route first so traffic returns to its previous path, then investigate the Worker deployment. If an older route was replaced, restore its exact pattern and script. Verify both cached and uncached requests after rollback.
