URL Rewrite Data

A headless storefront still needs Magento’s URL rewrites — the map of clean URLs to products, categories and CMS pages, plus every 301/302 redirect. URL Rewrite Data bundles all of them into a versioned JSON snapshot and GraphQL feed so your Astro frontend can resolve any incoming path (and issue redirects) at the edge. It also includes a genuinely safe .htaccess redirect importer for migrating legacy redirects.

Compatibility

Magento

Open Source 2.4.9 GA (and later 2.4.x).

PHP

Tested on 8.4 and 8.5.

Delivery

Versioned JSON snapshot + GraphQL feed.

Migration

Safe, reversible .htaccess import.

The rewrite bundle

GraphQL

{
  urlRewriteBundle {
    store_code count version
    rewrites { request_path target_path redirect_type entity_type }
  }
}

Every rewrite for the store — product, category, CMS and custom — with a version hash so your build can skip a rebuild when nothing changed.

Snapshot

From URL Rewrite Bundle, click Refresh to write a JSON snapshot, then Download it or pull it in your build pipeline. A plugin on Magento’s rewrite persistence keeps the data fresh as you edit the catalogue.

Migrate legacy redirects from .htaccess

Moving from a legacy platform? Paste your old .htaccess and import the redirects — safely.

1. Open Import .htaccess Redirects, paste your whole .htaccess (or just the redirect block).

2. Click Preview — a dry run classifies every line into ready, needs-review (regex), collision or unsupported, writing nothing.

3. Click Import to commit the ready rows. Refresh the URL Rewrite Bundle and your headless storefront picks them up.

Safe and reversible by design

Imported rows are stamped as a distinct type (htaccess_custom). The importer never touches your product, category or CMS rewrites — a pasted line that collides with one is reported, not applied — and Remove all imported cleanly undoes the whole import. Only Redirect/RedirectMatch 301/302 lines are read; RewriteRule, IP blocks and everything else are ignored.

Correct & safe

Unsafe targets neutralised

A redirect target that isn’t a normal http(s) URL is forced to a same-site path, so a javascript: or protocol-relative (//evil.com) target in a pasted file can’t become an open-redirect or script URL.

Only literal redirects

RedirectMatch rules with real regex are flagged for manual review rather than guessed at — only a literal, fully-anchored path maps cleanly to a rewrite, so nothing is imported wrong.

Never clobbers Magento rewrites

Import, update and delete all operate only on the import marker, in a single transaction — your catalogue’s own rewrites are never modified or removed.

Admin-only

Every bundle and import action is permission-gated, and the snapshot download path is sanitised.

FAQ

Why does a headless storefront need this?

Your frontend has to know how to resolve clean URLs to products/categories/pages and honour every 301/302 redirect. The bundle hands it the whole rewrite map (with a version hash) in one call, so it can route and redirect at the edge without querying Magento per request.

Is the .htaccess import safe to run on a live store?

Yes. It previews as a dry run first, only ever writes/updates/deletes rows it owns (htaccess_custom), reports anything that would collide with a real Magento rewrite instead of touching it, and can be fully undone with one click.

What happens to a javascript: or //evil.com redirect target?

It’s forced to a same-site path (e.g. /javascript:…), so it can’t act as a script URL or an open-redirect to an external site. Genuine http(s):// targets you intend are kept as-is.

Which .htaccess lines actually get imported?

Only Redirect and RedirectMatch directives with a 301 or 302 status, and only when the path is a literal (regex patterns are flagged for review). Everything else — RewriteRule, IP/country blocks, gzip, comments — is ignored, so pasting a whole file is safe. Verified clean on PHP 8.4 and 8.5.