AWS Amplify Support

AWS Amplify redirects and rewrites for single-page apps.

A single-page app has one real file, index.html, and uses client-side routes. Refresh or open a deep link and Amplify looks for a file that does not exist and returns 404. A 200 rewrite fixes that, but a careless rule also swallows your static assets. We write the rules in the right order.

Get Expert Help › All AWS Services
200 rewriteServes index.html, keeps the URL
301 / 302Redirects the browser
Rule orderFirst match wins
customHttp.ymlCustom response headers

When You Need This

The situations where this work pays for itself.

Signs it is time

  • Refreshing or opening a deep link returns 404 on Amplify
  • Assets such as CSS or JS are returned as HTML after adding a rewrite
  • You need www to apex, or HTTP to HTTPS, redirects
  • You want to proxy /api paths to another origin
  • Old URLs need permanent redirects after a redesign

What you get

  • A rewrite and redirect rule set with comments
  • Test results for deep links and static assets
  • Header rules where needed
  • A note on SSR versus static behavior

How we do it

A clear, safe process you can follow along with.

1. Confirm the cause

We load a deep link and look at the response in the browser network tab. A 404 from Amplify with the framework's own app not loading means no rewrite exists for that path.

2. Add the SPA rewrite

In Rewrites and redirects, we add a rule with a source pattern that excludes file extensions, target /index.html and type 200 (Rewrite). Amplify documents a regular expression for this that skips common static asset types.

3. Order rules carefully

Rules are evaluated top to bottom. Specific redirects and API proxies go above the catch-all rewrite, otherwise the rewrite catches everything first.

4. Add redirects

We add 301 redirects for moved pages and for www to apex consolidation, and use the domain settings for canonical host redirects. 302 is used only for temporary moves.

5. Proxy APIs if needed

A 200 rewrite to an external URL can proxy a path to another origin, though CORS, caching and headers differ from a direct call. For complex needs we put an API Gateway or CloudFront behavior in front.

6. Check server-side rendered apps

SSR frameworks on Amplify handle routing in the compute layer, and a blanket index.html rewrite can break them. We use framework-specific settings instead.

7. Test and verify

We test deep links, refreshes, file requests, old URLs and trailing slashes, and confirm status codes with curl.

Mistakes we help you avoid

Common ways this goes wrong, and what we do instead.

A catch-all rewrite that includes assets

Scripts and styles return HTML, and the app shows a blank page.

Using 301 where 200 is needed

A redirect changes the URL and breaks client-side routing state.

Rules in the wrong order

A more specific rule placed below the catch-all never runs.

Applying SPA rules to an SSR app

It can bypass server rendering.

Frequently Asked Questions

Why do I get 404 when I refresh on Amplify?

Deep link paths do not exist as files. Without a 200 rewrite to index.html, Amplify returns 404 instead of letting the app route.

What is the difference between a rewrite and a redirect?

A 200 rewrite serves different content at the same URL. A 301 or 302 redirect tells the browser to go to a new URL.

Can I set custom headers on Amplify?

Yes. You can define headers for paths, such as security and caching headers, through a customHttp.yml file or the console. We check the current format when we set it up.

Want Help With AWS Amplify redirects and rewrites for single-page apps?

Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.

Schedule Appointment › No commitment required