Redirects are rules that instruct Vercel to send users to a different URL than the one they requested. For example, if you rename a public route in your application, adding a redirect ensures there are no broken links for your users. There are two types of redirects you can use on Vercel:
Dynamic: Dynamic redirects are used to redirect users to a different domain. They can be implemented using Vercel Functions, or Middleware.
Static: Static redirects are used to redirect users to a different page on the same domain. They can be implemented using the Vercel dashboard or configuration-based redirects.
With redirects on Vercel, you can define HTTP redirects in your application's configuration, regardless of the framework that you are using, including both dynamic and static redirects. Redirects are processed at the Edge across all regions.
Moving to a new domain: Redirects help maintain a seamless user experience when moving a website to a new domain by ensuring that visitors and search engines are aware of the new location.
Replacing a removed page: If a page has been moved, temporarily or permanently, you can use redirects to send users to a relevant new page, thus avoiding any negative impact on user experience.
Canonicalization of multiple URLs: If your website can be accessed through several URLs (e.g., acme.com/home, home.acme.com, or www.acme.com), you can choose a canonical URL and use redirects to guide traffic from the other URLs to the chosen one.
Geolocation-based redirects: Redirects can be configured to consider the source country of requests, enabling tailored experiences for users based on their geographic location.
For dynamic, critical redirects that need to run on every request, you can use Middleware and Edge Config.
Redirects can be stored in an Edge Config and instantly read from Middleware. This enables you to update redirect values without having to redeploy your website.
You can use configuration-based redirects to generate routing rules during the build process. This includes temporary redirects (307), permanent redirects (308), and geolocation-based redirects.
Configuration-based redirects can be defined in framework-specific config file or in the vercel.json file, which is located in the root of your application. The vercel.json should contain a redirects field, which is an array of redirect rules. For more information on all available properties, see the project configuration docs.
When using Next.js, you do not need to use vercel.json. Instead, use the framework-native next.config.js to define configuration-based redirects.
In emergency situations, you can also define redirects using Firewall rules to redirect requests to a new page. Firewall redirects execute before CDN configuration redirects (e.g. vercel.json or next.config.js) are evaluated.
Vercel supports both temporary and permanent redirects.
307 Temporary Redirect: Not cached by client, the method and body never changed. This type of redirect does not affect SEO and search engines will treat them as normal redirects.
302 Found: Not cached by client, the method may or may not be changed to GET.
308 Permanent Redirect: Cached by client, the method and body never changed. This type of redirect does not affect SEO and search engines will treat them as normal redirects.
301 Moved Permanently: Cached by client, the method may or may not be changed to GET.
We recommend using status code 307 or 308 to avoid the ambiguity of non GET methods, which is necessary when your application needs to redirect a public API.
There are some best practices to keep in mind when implementing redirects in your application:
Test thoroughly: Test your redirects thoroughly to ensure they work as expected. Use a preview deployment to test redirects before deploying them to production
Use relative paths: Use relative paths in your destination field to avoid hardcoding your domain name
Use wildcards carefully: Wildcards can be powerful but should be used with caution. For example, if you use a wildcard in a source rule that matches any URL path, you could inadvertently redirect all incoming requests to a single destination, effectively breaking your site.
Prioritize HTTPS: Use redirects to enforce HTTPS for all requests to your domain