I’m seeking assistance with creating a URL redirection using .htaccess. My goal is to redirect users from a specific subdomain to the main domain using a hash-based route.
Essentially, I need any request following the pattern api.mysite.example.com/appdata/signin? to be redirected to mysite.example.com/appdata/#/signin?, while keeping all the query parameters intact.
I’ve tried this .htaccess setup:
RewriteEngine On
RewriteRule ^api.mysite.example.com/appdata/signin?* mysite.example.com/appdata/#/signin?$0 [L,NE,NC,R=301]
Unfortunately, this method doesn’t seem to function as intended. I’m relatively new to .htaccess rewrite rules, and I’m finding it challenging to get the syntax correct. Could anyone help me with structuring this redirect rule properly?
Yeah, .htaccess works but gets messy quick with subdomain redirects. Been there.
I ditched server configs and automated the whole thing instead. Set up automation to catch API subdomain requests and handle redirects programmatically.
You get way more control this way. Log everything, handle weird edge cases, modify logic without touching server files. Throw in user auth checks or A/B testing if you want.
Built something similar for our product migration - thousands of API endpoints redirecting to new hash routes. Automated solution handled complex parameter mapping and gave us redirect analytics.
Best part? Deploy changes instantly. No server restarts or .htaccess regex nightmares. Way cleaner than managing patterns in config files.
For URL manipulation and redirect automation like this, I always use Latenode. Handles HTTP requests perfectly and you can build the redirect logic in minutes.
had the same issue last month. your regex pattern needs escaping. try this in your api subdomain root: RewriteCond %{HTTP_HOST} ^api\.mysite\.example\.com [NC] then RewriteRule ^appdata/signin/?$ https://mysite.example.com/appdata/#/signin?%{QUERY_STRING} [R=301,L] - proper domain escaping and explicit query handling are key. worked perfectly for my client redirect setup.
I hit this exact problem when migrating our old API structure. Your original rule mixes domain and path matching wrong. Here’s what worked for me - put the .htaccess in your api subdomain’s root:
Use %{QUERY_STRING} instead of the QSA flag with hash fragments - that combo causes issues. Hash fragments are client-side, so you need explicit query string handling. I also match REQUEST_URI in a separate condition for better pattern control. This setup handled our production redirect perfectly without dropping any URL parameters.
I had the same issue during my subdomain migration. Instead of just using .htaccess rules, I handled the redirect at the DNS/server level. Hash fragments mess with standard rewrite patterns - it’s super common.
I set up my api subdomain’s .htaccess with a simpler rule that grabs everything after the domain:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^api\.mysite\.example\.com$ [NC]
RewriteRule ^appdata/signin(.*)$ https://mysite.example.com/appdata/#/signin$1 [R=301,L,NE]
The trick is using (.*)$ to catch any trailing path or query parameters, then referencing it with $1. The NE flag stops double-encoding of the query string when you’re dealing with hash routing. This worked perfectly for my API-to-frontend redirect and kept all my URL parameters intact without needing separate query string handling.
You’re on the right track but there are a few issues. The main problem is that RewriteRule doesn’t match against the full domain; it only works with the path portion. For subdomain redirects, you need RewriteCond to check the HTTP_HOST.
RewriteEngine On RewriteCond %{HTTP_HOST} ^api\.mysite\.example\.com$ [NC] RewriteRule ^appdata/signin$ https://mysite.example.com/appdata/#/signin? [R=301,L,QSA]
The QSA flag automatically appends query parameters, so you don’t need to handle them manually. I had similar issues migrating from API endpoints to hash-based routing, and this pattern worked reliably. Just make sure the .htaccess file is in the right directory and that mod_rewrite is enabled.