Enhancements to favicon handling in WordPress 5.4

WordPress 3.0 introduced wp_favicon_request() to avoid the performance hit that comes from serving a full 404 page on every favicon request. While that function works as intended, it doesn’t offer enough flexibility.

As of WordPress 5.4, theme and plugin authors can manage favicon requests much more flexibly, with the following logic:

  • If there is a Site Icon set in Customizer, redirect /favicon.ico requests to that icon.
  • Otherwise, use the WordPress logo as a default icon.
  • If a physical /favicon.ico file exists, do nothing and let the server handle the request.

This logic will only work if WordPress is installed in the root directory.

With these changes, /favicon.ico handling is now more consistent with /robots.txt requests.

New functions & hooks

WordPress 5.4 introduces a bunch of new functions and hooks for favicon handling:

  • is_favicon() conditional tag to complement is_robots().
  • do_favicon action to complement do_robots and use it in template loader. This hook will be fired when the template loader determines a favicon request.
  • do_favicon() function, hooked to the above action by default, to complement do_robots().
  • do_faviconico action to complement do_robotstxt, for plugins and themes to override the default behavior. This hook will be fired when displaying the favicon file.

With the above logic, do_favicon redirects to the Site Icon if it exists, or to WordPress logo as a default icon, using the following code:

function do_favicon() {
     * Fires when serving the favicon.ico file.
     * @since 5.4.0
    do_action( 'do_faviconico' );

    wp_redirect( get_site_icon_url( 32, admin_url( 'images/w-logo-blue.png' ) ) );

Themes and plugins developers can use do_faviconico action to override the default behavior.


  • wp_favicon_request() is now deprecated in favor of do_favicon().

For reference, see the related ticket on WordPress Core Trac: #47398

#5-4, #dev-notes, #favicon