Pages _redirects should be able to override existing files
Summary
Currently, _redirects on GitLab Pages only apply when the requested file does not exist.
If a file exists, GitLab Pages always serves it (or applies its own 302 trailing-slash normalization), ignoring _redirects.
This makes _redirects much less useful in practice, especially for domain-level redirects and canonicalization.
(Discussion on the forum: https://forum.gitlab.com/t/redirects-doesnt-work-as-expected/130089)
Current behavior
-
_redirectsare only applied for non-existent paths. - For existing files, GitLab Pages serves the file instead of applying the redirect.
- Example from the docs:
/hello.html /world.html 302
If hello.html exists, the redirect is ignored.Why this is a problem
Domain canonicalization is impossible Redirects like www.example.com/* → example.com/:splat or sub.example.com/* → example.com/path/ do not work for existing pages, only for 404s. SEO best practices are blocked Search engines may index both www and non-www versions, causing duplicate content issues. Site migrations and restructuring are unreliable Redirects are supposed to help in moving content, but as soon as files exist, the redirect stops working.
In practice, _redirects end up acting as a “404 safety net,” not a real redirect mechanism.
Why this matters
Developers expect _redirects to provide reliable canonicalization (as with Netlify). Domain and path-level redirects are a common requirement for websites. Current behavior makes domain-level redirects almost pointless, which is confusing.
Proposed solution
Introduce a force override option for _redirects, similar to Netlify’s force flag.
Example syntax:
https://www.example.com/* https://example.com/:splat 301!
(! = force override, even if the file exists)Benefits
Proper support for domain canonicalization (www → apex). Cleaner SEO and reduced duplicate content. More flexibility for migrations and subdomain → path redirects. Brings GitLab Pages closer to feature parity with other static hosts