How Friendly URLs Work
A friendly URL turns an address full of parameters into one a person can read and share.
Where to find it
Architect Panel → Configuration:
- Friendly URLs — the rules that generate readable addresses
Architect Panel → Data:
- Datastores — the records a rule generates paths for
A rule belongs to a datastore
Each rule names a root path and a configuration: which datastore, which field supplies the text, what prefix the real destination uses, what replaces spaces, and — where records nest — which field points at the parent.
So one rule covers an entire datastore rather than being written per record.
Paths are generated as records change
Creating, updating, restoring or rolling back a record runs the rule for its datastore. So the addresses stay in step with the data without anybody maintaining them.
Uniqueness is handled
If a generated path is already taken, a number is appended until it is not. Two products called "Blue Widget" get distinct addresses rather than one overwriting the other.
Which is convenient and worth knowing: an address ending in a 2 usually means a duplicate name rather than a mistake.
The cache is the routing table
Generated paths are held in a cache mapping each path to its real destination, along with the rule and the record it came from. That is what the site actually consults when a request arrives.
So if an address is not resolving, the question is whether it is in the cache — not whether the rule looks right.
Nested records produce nested paths
Where a rule names a parent field, the path reflects the hierarchy. A category three levels deep produces an address showing all three, which is both readable and good for search engines.
Choose the source field carefully
It should be something meaningful, stable and unlikely to be edited casually. A name is usually right; a description is too long, and a status is not unique.
Friendly URLs are a security-sensitive area
The routing tables are on the platform’s protected list, because anybody able to write to them could redirect your addresses somewhere else. They are not editable through the API for that reason.
Set them up before launch
Addresses that change after publication break bookmarks, links and search rankings. Getting the path structure right first is much cheaper than redirecting later.
Worked example
A site generates product addresses from the product name under a products root, with categories nested by their parent field. Two identically named products produced distinct addresses automatically. When a page stopped resolving, the cache showed the record had been renamed and the old path was simply gone.
Recommendations
- Generate from a stable, meaningful field.
- Check the cache when an address does not resolve.
- Settle the path structure before launch.
- Treat the routing tables as sensitive.