[MillanWangShopify]

WHY are these changes introduced?

Vault issue: https://vault.shopify.io/teams/16949-Dev-Experience/issues/92474-error-bad-response-301

shopify theme profile --url <path> fails with Error: Bad response: 301: , with no hint about the cause, and it's reported to Bugsnag as an unexpected crash.

• About two thirds of the 301s come from a --url with a query string. profile passed the whole --url as the path, and the renderer appends its own ?_fd=0&pb=0. That built /search?q=kw?_fd=0&pb=0, which drops _fd=0, so stores with a custom primary domain redirect to that domain. theme dev doesn't have this bug because it already passes the path and query separately.
• The rest are pages that redirect on the storefront (URL redirects, markets), plus a few 302s to /password on password-protected stores.

WHAT is this pull request doing?

• Splits --url into a path and a query before rendering. The #fragment is dropped, and a user-supplied _fd or pb is removed so the renderer's values always apply (the param list is now exported from storefront-renderer.ts). An absolute --url is accepted, and only its path and query are used; the flag description now says so.
• Rejects a --url that can't be parsed (it used to throw a TypeError) or that starts with // (it was parsed as a host, so another page was profiled).
• Raises an AbortError when the page redirects, and shows the destination without _fd/pb:
  • a store-relative destination is suggested as the next --url,
  • an absolute destination, which can be another host such as customer accounts, is shown in full, and its path is suggested only "if that page is on your storefront",
  • a destination with the same path and query as the request isn't suggested, so scripts and agents don't retry the same redirect,
  • a redirect to /password suggests checking --store-password.
    Redirects aren't followed automatically.
• Raises an AbortError for other non-200 responses, with the status, the request ID, and the body only when it's JSON or short (never a full HTML page). This includes storefront 5xx responses: they aren't caused by the user, but the CLI can't act on them, so reporting them as CLI crashes in Bugsnag only adds noise.

Out of scope: why a password-protected preview render can still get a 302 to /password after the password check passes.

Before:

Error: Bad response: 301:

After (page that redirects):

The page /pages/old redirects (301) instead of rendering, so it can't be profiled.
It redirects to /pages/new. Run the command again with --url "/pages/new".

How to manually test your changes?

On a dev store you own, ideally one with a custom primary domain:

pnpm shopify theme profile --store <store> --url "/search?q=test" --json
pnpm shopify theme profile --store <store> --url "/collections/all?page=2" --json

Both should return a profile. Then add a URL redirect (Admin → Content → Menus → URL redirects) and profile its source path: the error should suggest the destination.

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've considered analytics changes to measure impact
• The change is user-facing — I've identified the correct bump type (patch for bug fixes · minor for new features · major for breaking changes) and added a changeset with pnpm changeset add

[karreiro]

Thank you, @MillanWangShopify!