Skip to main content

​
Domain migration: rocky.global → app.rocky.global

This document describes the risks of moving the main application domain from rocky.global to app.rocky.global and how to mitigate them using 301 permanent redirects.

​
1. Risks

​
1.1 SEO and indexing

  • Risk: Search engines have indexed rocky.global. Changing the domain without redirects causes:
    • Loss of rankings and organic traffic.
    • Old URLs return 404 or point to the wrong site.
  • Mitigation: Redirect every URL from rocky.global (and www.rocky.global) to the same path on app.rocky.global with HTTP 301 (Moved Permanently). Search engines transfer most of the “link equity” to the new URLs and update their index over time.

​
1.2 External links and bookmarks

  • Risk: Third-party sites, emails, and user bookmarks point to https://rocky.global/.... Without redirects they break.
  • Mitigation: Same 301 redirects: https://rocky.global/path → https://app.rocky.global/path. Links and bookmarks keep working.

​
1.3 Sessions and cookies

  • Risk: Cookies are often set for the current host (rocky.global). After moving to app.rocky.global, existing cookies may not be sent, so users can be logged out.
  • Mitigation:
    • Set SESSION_DOMAIN=.rocky.global in .env so cookies are valid for both rocky.global and app.rocky.global during and after migration (if you want shared session across subdomains).
    • Or accept a one-time logout: after 301, users land on app.rocky.global and log in again; new cookies will be for app.rocky.global.

​
1.4 Emails and callbacks

  • Risk: Links in emails (password reset, order confirmation, etc.) and payment/API callbacks (e.g. Redsys) may use the old domain.
  • Mitigation:
    • APP_URL: Set APP_URL=https://app.rocky.global in .env so Laravel generates all new links with the new domain.
    • 301 redirects: Any old link (e.g. https://rocky.global/password/reset/...) will redirect to https://app.rocky.global/..., so old emails and callbacks still work.
    • Redsys / payment gateway: Update notification and return URLs in the gateway dashboard to https://app.rocky.global/... when possible; redirects cover any remaining old URLs.

​
1.5 CORS and Sanctum

  • Risk: If the frontend or API consumers use the domain in CORS or Sanctum’s stateful domains, the old domain may stop working.
  • Mitigation:
    • Set APP_URL=https://app.rocky.global; Sanctum uses this for allowed hosts.
    • Keep 301 redirects so that requests to rocky.global are redirected to app.rocky.global before hitting the app; then CORS and Sanctum see the canonical host.

​
1.6 SSL/TLS

  • Risk: Both rocky.global and app.rocky.global must have valid certificates. Redirects should use HTTPS on the new domain.
  • Mitigation: Configure SSL for both domains (e.g. wildcard *.rocky.global or separate certs). The application redirects to https://app.rocky.global.

​
1.7 Hardcoded domain references

  • Risk: Code or config that hardcodes rocky.global (e.g. support email, asset URLs) can point users to the wrong place.
  • Mitigation: Use config('app.url') (and thus APP_URL) for the app’s base URL. Support email (support@rocky.global) can stay as is; it’s an email address, not the app domain. No change required unless you move support to e.g. support@app.rocky.global.

​
2. Redirect strategy (301)

​
2.1 Rules to implement

  • Redirect all requests from the old host(s) to the same path (and query string) on the new host, with 301:
  • Preserve path and query string (e.g. /events/123/dashboard?tab=orders → https://app.rocky.global/events/123/dashboard?tab=orders).
  • Use 301 so search engines and clients treat the move as permanent and update caches/bookmarks.

​
2.2 Where redirects are implemented in this project

  1. Laravel middleware (App\Http\Middleware\RedirectOldDomain):
    Runs on every request. If the request host is one of the configured “old” domains (e.g. rocky.global, www.rocky.global), it returns a 301 to the same path/query on the canonical URL from config('app.url') (i.e. APP_URL).
    This works regardless of web server (Apache, Nginx, load balancer).
  2. Optional: Apache .htaccess (in public/.htaccess):
    If the app is served by Apache and the old domain points to the same document root, you can uncomment the redirect block at the top of public/.htaccess. This redirects at the web server level (before PHP) and reduces load.
    The middleware still handles any request that reaches Laravel (e.g. behind Nginx or a reverse proxy), so redirects work even if you do not use the .htaccess rules.

​
2.3 Configuration

  • .env
    • APP_URL=https://app.rocky.global
      This is the canonical application URL; all new links and the redirect target use it.
    • Optional: REDIRECT_OLD_DOMAINS=rocky.global,www.rocky.global
      If not set, the middleware uses the default list in config/domain.php (see below).
  • config/domain.php (optional)
    • redirect_old_domains: list of hosts that must be redirected to APP_URL with 301.

​
3. Checklist before and after cutover

Before:
  • DNS: app.rocky.global points to the same application server (or load balancer).
  • SSL certificate valid for app.rocky.global (and ideally for rocky.global and www.rocky.global for redirects).
  • .env: APP_URL=https://app.rocky.global.
  • .env: Optional REDIRECT_OLD_DOMAINS=rocky.global,www.rocky.global if you use custom list.
  • Payment gateway / Redsys: Update notification and return URLs to https://app.rocky.global/... where possible (redirects still cover old URLs).
  • Deploy middleware and (if used) .htaccess changes so 301s are active as soon as both domains hit the app.
After:
  • Test: https://rocky.global and https://rocky.global/any/path return 301 and Location: https://app.rocky.global/....
  • Test: Login, password reset, and payment return URLs work via app.rocky.global and via old links (through redirect).
  • Google Search Console: Add https://app.rocky.global as a property and, if needed, submit a change of address or sitemap for the new domain.
  • Monitor logs and errors for broken links or callbacks still using the old domain; 301s should handle them transparently.

​
4. Summary

  • Risks: SEO, broken links, sessions/cookies, emails/callbacks, CORS/Sanctum, SSL, hardcoded URLs.
  • Mitigation: Use 301 redirects from rocky.global and www.rocky.global to app.rocky.global (same path and query), set APP_URL=https://app.rocky.global, and optionally SESSION_DOMAIN=.rocky.global if you want shared cookies. Redirects are implemented in Laravel middleware (and optionally in Apache .htaccess).