LinkShift.App for domain-group routing
Create domain groups, attach domains, and publish redirect rules with regex, placeholders, and conditional logic. Keep every environment aligned with a single source of truth.
Watch the first domain + redirect rule setup
A quick walkthrough showing how to attach your first domain and publish a rule on LinkShift.App.
Three building blocks, one predictable workflow
LinkShift.App keeps your rules structured. Domain groups own the routing logic, domains inherit it, and rules stay ordered and explicit.
Domain group
One group defines the redirect rules, limits, and defaults that apply to each assigned domain.
Domains
Attach production, staging, or regional domains and keep routing consistent by design.
Redirect rules
Ordered rules support regex sources, placeholders, modifiers, and inline conditions.
Rules that stay readable and precise
Match exactly what you need, transform data safely, and keep destinations predictable.
Regex-ready sources
Match literal paths or /pattern/flags with capture groups for precise routing.
Template variables
Use {path}, {query.*}, {segments.*}, and {domain.fqdn} to build dynamic targets.
Modifiers for output
Transform data with :to_lower_case, :url_encode, or :auto_trailing_slash.
Conditional destinations
Route by method or time with inline condition expressions.
Path + query match modes
Use path prefix matching with query exact, ignore, or subset rules.
Link maps for short links
Resolve short keys into destinations with fallback routing and case controls.
Organization-aware limits
Respect domain group, domain, and rule limits per organization.
Shared governance
Keep redirects organized, reviewed, and consistent across environments.
Support path prefix routing alongside query match modes (exact, ignore, or subset) to keep redirects precise without losing flexibility. Add link maps to resolve short keys into full destinations with optional fallbacks.
Plans that grow with your traffic
Start free and scale only when your redirect inventory demands it.
SSL is included for every domain, so traffic is always served over HTTPS.
Rule syntax that mirrors real traffic
Use regex, placeholders, and conditions to build consistent redirection logic.
Campaign capture with source tracking
Regex groups keep the identifier, placeholders keep the context.
/^\/promo\/(\d+)$/https://app.example.com/campaign/$1?from={domain.fqdn}The destination stays valid for any assigned domain in the group.
Preserve query parameters
Carry UTM data while moving to a new host.
/^\/go\/(.*)$/https://store.example.com/$1?utm={query.utm}Use modifiers like {query.utm:url_encode} when values can include spaces.
Method-aware routing
Route by method without duplicating rules for each domain.
/^\/support\/(.*)$/method == "POST" ? https://api.example.com/write/$1 : https://api.example.com/read/$1Conditions support operators like ==, !=, <=, >=, ~=, and includes.
Variables are resolved from request context including path, query parameters, segments, and domain metadata.
Keep routing safe, fast, and auditable
Domain groups help teams work in parallel without losing control of critical redirects.
Predictable governance
Centralize rules at the group level and avoid divergent redirects across brands, regions, or environments.
30-day satisfaction window
If the platform is not the right fit, request a refund within 30 days with no explanation required.
Questions teams ask before switching
Quick answers for architects, developers, and ops teams.
In most cases, no. Rules live at the domain group level and apply to each domain assigned to that group.
Yes. Provide regex patterns in /pattern/flags format and reference capture groups with $1, $2, and so on.
You can use {path}, {query.*}, {segments.*}, and {domain.*}, plus modifiers.
If the platform is not a fit, you can request a refund within 30 days with no explanation required.
Build your redirect model in minutes
Set up a domain group, attach domains, and publish rules with full context.