Redirects

Redirects move a request from one location to another with an HTTP status. You use them to canonicalize a hostname (apex → www or the reverse), retire old URLs after a site restructure, and forward parked domains at your real site. managed.dev applies redirect rules at the edge, before the request reaches WordPress, so they’re fast and they work even for paths that no longer exist in the app.

Note

You don’t need a rule for http → https — that redirect is on automatically for every hostname, backed by automatic TLS. Write redirect rules for the cases below, not for forcing HTTPS.

Anatomy of a rule

Each rule has three parts:

• source — the incoming hostname and/or path to match, for example example.com or /old-blog/*.
• destination — where to send the request, for example https://www.example.com or /blog/$1 when the source captured a wildcard.
• status code — 301 for a permanent move (the default; search engines update their index) or 302 for a temporary one.

Tip

Use 301 for permanent canonicalization and retired URLs so link equity and bookmarks follow the move. Reserve 302 for genuinely temporary forwards, like a campaign landing page you’ll take down.

Common patterns

Apex ↔ www

Pick one canonical hostname and forward the other to it. Set the canonical one as your primary domain, then redirect the alternate:

Redirect apex to www

source:      example.com/*
destination: https://www.example.com/$1
status:      301

To go the other way (www → apex), just swap the source and destination hostnames.

Legacy URL maps

After restructuring a site, forward old paths to their new homes so existing links and search results don’t 404:

Retire an old section

source:      /products/2023/*
destination: /shop/$1
status:      301

Parked and marketing domains

Forward a secondary domain you own at your main site so it doesn’t sit empty. Attach the domain to the site first (custom domains), then add a rule sending all of its traffic to the primary hostname.

How to manage redirects

1. Open your site in the dashboard and go to the Redirects tab.

2. Choose Add rule, enter the source pattern and destination, and pick the status code.

3. Save. The rule takes effect at the edge within moments — no deploy required.

The Redirects tab for a site in the app.managed.dev dashboard: a table of rules with source pattern, destination, and status-code columns, an enabled toggle per row, and an “Add rule” button.

You can also manage rules over the API. Redirects live alongside cache settings in the resource model, so they use the cache:write scope:

cURL

Add a redirect rule

curl https://api.managed.dev/v1/sites/site_01J7.../redirects \
  -H "Authorization: Bearer mfk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "source": "example.com/*",
    "destination": "https://www.example.com/$1",
    "status": 301
  }'

mf CLI

Add a redirect rule

mf redirects add \
  --site site_01J7... \
  --source 'example.com/*' \
  --destination 'https://www.example.com/$1' \
  --status 301

Developer preview

The public /v1 API and the mf CLI are in active developer preview. The dashboard Redirects tab is the supported surface today; the redirect schema may change before general availability.

Next steps

Custom domainsAttach hostnames and choose the primary domain redirects point at.

Cache & redirects APIThe full schema for redirect rules and cache settings over the API.

TLS certificatesWhy you never write an http to https rule — it's automatic.