Make WordPress Core

Opened 7 years ago

Last modified 6 years ago

#40082 reopened enhancement

Pretty links for users when searching

Reported by: henrywright's profile henry.wright Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.7.3
Component: Canonical Keywords:
Focuses: Cc:


When using the site search, users are shown the ugly URL when taken to the results page:

It appears as though search results can have pretty URLs:

Maybe show the pretty URL in the browser instead?

Change History (10)

#1 @lukecavanagh
7 years ago


You can already do this using the wp_redirect function.

Add this to the site functions.php or as a code snippet.

function wp_change_search_url_rewrite() {
        if ( is_search() && ! empty( $_GET['s'] ) ) {
                wp_redirect( home_url( "/search/" ) . urlencode( get_query_var( 's' ) ) );
add_action( 'template_redirect', 'wp_change_search_url_rewrite' );


#2 @henry.wright
7 years ago

Hey Luke! Thanks; I am aware that can be done.

#3 @lukecavanagh
7 years ago


So would you want the default search URL to be changed for search or an option for being able to change it?

The filter based method does work fine though.

I think changing the default search URL, has a couple of improvements.

The first is that bots will search a WP site, so the way to fix the default is by changing /?s=keyword to /search/keyword. Then you redirect the default back to home /.

Changing the default search URL is clearer for users of the site as well.

Your thoughts?

#4 @henry.wright
7 years ago

The filter based method does work fine though.

Yes, the filter works great but the reason for opening the ticket wasn't to improve my own site; rather, it was to improve the core project :)

#5 @Cybr
7 years ago

  • Component changed from General to Canonical

Core function redirect_canonical(), which invokes basic redirects, explicitly states:

Prevents redirection for feeds, trackbacks, searches, and admin URLs. Does not redirect on non-pretty-permalink-supporting IIS 7+, page/post previews, WP admin, Trackbacks, robots.txt, searches, or on POST requests.

The function contains this very early:

// ...code
if ( is_trackback() || is_search() || is_admin() || is_preview() || is_robots() || ( $is_IIS && !iis7_supports_permalinks() ) ) {
// code...

As for why I do not know, maybe it caused a regression?
I do want to see this enhancement, especially since /search/ currently does work as intended.

#6 @lisota
7 years ago

  • Resolution set to invalid
  • Status changed from new to closed

This will break basic Google Analytics site search tracking on WordPress sites. Google Analytics looks for a query string with the search term, 's' or another one if you specify it.

Changing the URL to a pretty permalink breaks this and requires additional coding workarounds to surface search terms in Google Analytics, which is a bad thing.

Since this already works if someone wants to use /search/, I don't think there is anything to do here.

Supporting Google Analytics site search tracking seems far more important than a "clean" URL for the vast majority of users, so the default should be left as is. I don't believe this change "improves" the project.

#7 @lisota
7 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

#8 @henry.wright
7 years ago

I hadn't considered that. Whilst I think pretty URLs would be nice to have, I agree we can't break most people's site tracking.

#9 @Cybr
7 years ago

Analytics plugins can simply expand their script when users are reaching search pages (Option 2):

Option 2: Customize the tracking code on your results page to dynamically specify a virtual page path that includes the query keywords. The tracking code on the results page would look something like:

analytics.js: ga('send', 'pageview', '/search_results.php?q=keyword');

In WordPress' case:

analytics.js: ga('send', 'pageview', '/search/keyword/?s=keyword');

#10 @Cybr
6 years ago

get_search_link() already returns the pretty URL:

I still don't know why is_search() has been hardcoded as an exclusion in redirect_canonical(). I'd love to hear an explanation from the Core team.

I consider this inconsistent behavior with WP_Rewrite's rules.

Note: See TracTickets for help on using tickets.