<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=569360) </details> <!--IssueSummary end--> ## Background Following the implementation of in-page file search in #430775, we need to determine the best approach for handling the existing find file page at `/-/find_file/`. ## Proposal As suggested by @derekferguson in #430775, the safest approach would be to: 1. **Redirect the existing page** (`/-/find_file/`) to the repository page with the file search automatically opened 2. **Monitor usage** after the redirect is implemented to understand: - How many visits the URL still receives - Whether people have bookmarked the direct URL - If there are external links pointing to this page ## Implementation Steps 1. Implement redirect from `/-/find_file/` to repository page with search opened 2. Add analytics/monitoring to track: - Number of redirects from the old URL - User behavior after redirect 3. Based on data collected, decide whether it's safe to completely remove the page ## Success Criteria - [ ] Redirect is implemented and working correctly - [ ] Analytics are in place to monitor usage - [ ] Data collection period completed (suggest 1-2 release cycles) - [ ] Decision made on permanent removal based on usage data ## Related Issues - #430775 - Allow for find file search to be on the page (parent issue) - #22426 - Context-aware file search (next iteration)