createRedirect
Create a permanent 301 redirect to preserve SEO when a URL path changes. Use this after API-triggered renames that BD does not auto-handle.
Instructions
Create a redirect - Create a new 301 redirect rule.
Use when: preserving SEO after any URL change - slug rename on a member profile, post, page, or category. BD auto-creates some redirects on its own (admin-triggered renames), but you must create them manually for API-triggered changes. Avoid duplicate old_filename values.
Required: old_filename, new_filename.
type is wrapper-managed: the wrapper hardcodes type=custom on every create. The other BD type values (profile, post, category) are reserved for BD's own auto-redirect logic on admin-triggered renames and are not exposed here.
Pre-check before create - TWO checks (redirects are uniquely dangerous: wrong rules cause infinite loops and SEO damage):
Check 1 - exact-pair skip (idempotent): Do a server-side filter-find: listRedirects property=old_filename property_value=<proposed old> property_operator==. If a row exists where new_filename also matches the proposed new, skip the create - the rule is already there; creating a duplicate just bloats the redirect table. If a row exists with the same old_filename but a DIFFERENT new_filename, that's a conflict: reuse via updateRedirect with the new target, OR ask the user which destination wins. Never silently create a duplicate or conflicting old_filename.
Check 2 - reverse-rule loop prevention (CRITICAL): Do a second filter-find: listRedirects property=old_filename property_value=<proposed NEW> property_operator==. If a row exists where new_filename equals your proposed old_filename, creating this rule would produce an infinite redirect loop (A->B and B->A). STOP. Flag to the user, explain the reverse rule in place, and ask whether to delete the existing reverse rule first or abandon the create.
Do NOT paginate unfiltered redirect lists - filtered lookups are two tiny responses. On any site with a large redirect history, dumping the full table wastes rate limit and context.
Parameter interactions:
old_filename/new_filename- URL paths relative to the domain root (not full URLs)db_id- database record ID of the source content if the redirect ties to one; otherwise 0
See also: updateRedirect (modify existing).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| old_filename | Yes | The old URL path being redirected from, relative to the domain root (e.g. old-slug, not the full URL) | |
| new_filename | Yes | The new destination URL path | |
| db_id | No | Database record ID of the source content object this redirect was generated from (0 if not tied to a record) | |
| id | No | Legacy secondary identifier; typically 0 for system-generated redirects |