Blog

You renamed a page, deleted a product or moved the site to a new domain. The old URL still sits in Google, in old emails and on other people’s sites, and right now it leads to a 404. A redirect sends that old address to the right new one and tells search engines whether the move is permanent.

Most sites need one plugin, a few minutes and a careful test. What goes wrong is rarely the rule itself. It is a second rule, somewhere else, that disagrees with it.

What do people mean by a “WordPress redirect page”?

Usually they mean a URL redirect, and that is what this guide covers. The phrase also gets used for four other things, and each one has a different fix:

• A URL redirect. An old URL forwards to a new one with a 301 or 302 status. This is the one that matters for SEO.
• A destination page. The page people land on after a login, a checkout, a form or a QR scan. These come from a plugin or WooCommerce setting, not from a redirect rule.
• A 404 page. When nothing relevant replaces the old URL, the honest answer is a helpful 404. Our guide to customizing the WordPress 404 page covers that.
• A page that forwards to another site. For example an affiliate link or a Linktree page. Use a redirect rule here too. Building a page and redirecting away from it is unnecessary.
• A redirect that is broken. “Too many redirects”, a login loop, or a rule that never fires. These are covered further down.

If you are changing URLs as part of a wider cleanup, the redirect decisions belong inside your WordPress SEO basics. Change a URL only once you have its redirect ready.

Should the redirect be a 301 or a 302?

Use a 301 when the move is permanent and a 302 when the original URL will come back. Google’s documentation on redirects treats 301 and 308 as permanent and 302 as temporary. Google uses a permanent redirect as a strong signal that the new URL is the one to show.

Renamed pages, merged posts, HTTPS moves and domain changes are all 301s. A seasonal promotion that takes over a URL for a month is a 302.

There is one practical exception. Browsers cache 301s, so a visitor who has followed one may never ask your server again. If you print a QR code or run a campaign link whose destination you will keep changing, use a 302 so a change actually reaches people. WooCommerce follows the same logic: its Product 404 Redirects extension sends trashed or private products through a 302 and permanently deleted ones through a 301.

Where should the redirect live on your site?

On most single sites, put it in a plugin. Redirects can be set in WordPress, on the server, in the host’s dashboard or at a CDN such as Cloudflare. Each layer has a job it does best:

Layer	Good for	Watch out for
A redirect plugin	Individual pages, 404 logs, importing a spreadsheet of old and new URLs	It only sees requests that reach WordPress. A PDF the server delivers directly never reaches the plugin.
.htaccess	Server-level rules on Apache or LiteSpeed	Nginx ignores it. A typo can give you a 500 error across the whole site.
Host redirect tool or Nginx config	Managed hosts and Nginx servers	Every host does it differently. Read their docs.
Cloudflare or DNS-level rules	Whole domains, especially an old domain after a rebrand	It is easy to forget a rule here when you are debugging WordPress.

Check your host before you write server rules. WP Engine, for example, has deprecated .htaccess and points customers to its portal rules, Nginx configuration or a plugin. If you are on Apache and want rules outside WordPress, our guide to writing .htaccess 301 redirects has the syntax.

For an old domain after a rebrand, keep the domain registered and redirect each page to its matching new page. Something still has to answer requests on the old domain. A Cloudflare or server rule is usually cheaper and simpler than keeping a second WordPress install running just to send visitors on.

How to redirect a page with the Redirection plugin

Redirection is the plugin most people recommend for this. It is free, it has no paid version, and its WordPress.org listing shows more than 2 million active installations. You need an administrator login, the old URL and the new URL.

1. Go to Plugins > Add New, search for Redirection, install it and activate it.
2. Open Tools > Redirection and complete the short setup. It can watch for permalink changes and log 404s. Turn on the 404 log, because it shows which dead URLs people actually visit.
3. Click Add New. In Source URL, enter the old path, for example /old-services-page/.
4. In Target URL, enter the full new address, for example https://example.com/services/.
5. Open the extra options and set the HTTP code to 301 for a permanent move, or 302 for a temporary one.
6. Save. Then test it as described below, not just in your logged-in browser.

Moving more than a handful of pages? Build the list in a spreadsheet with one row per old URL, then use Redirection’s import. For a redesign or migration, crawl the old site first so the list contains every URL, not just the ones you remember. If you would rather describe the change in chat and have it made and checked for you, that work is covered on our SEO and redirects page.

Where should each old URL point?

Point it at the page that does the same job as the old one. An old product goes to its replacement or, failing that, its category. An outdated guide goes to the guide that replaced it. Someone who clicked a link about blue running shoes and lands on your homepage has hit a dead end that just looks nicer.

That is why blanket “send every 404 to the homepage” plugins are a poor shortcut, popular as some of them are. If nothing replaces the old page, let it return a proper 404 with good navigation.

Two more rules from Google’s guidance on site moves:

• One hop, no chains. If page A already redirects to B and B now moves to C, edit the first rule to go straight from A to C. Then update your own links so they point at the final URL. Our guide to fixing internal links explains why every extra hop costs visitors and crawlers time.
• Keep migration redirects for at least a year where you can. Most owners keep them indefinitely. A rule that gets a few hits a month may still be catching a valuable backlink.

How do you check that the redirect worked?

Open the old URL in a private window, logged out. You should land on the new page in one step. Your admin session and cached pages can hide problems that a new visitor would see.

Then check the status code. A redirect checker shows each hop. From a terminal, this does the same:

curl -sI https://example.com/old-services-page/

A correct result shows HTTP/2 301 (or 302 if you chose that) and a location: line with your new URL. Running the same command on the new URL should return 200. If you see a second 301, you have a chain.

What if the redirect doesn’t fire?

The Redirection plugin’s support page lists the usual reasons, and they apply to most tools:

• Cache. Your browser or a page cache is serving the old response. Purge the site cache, the host cache and the CDN, then retest in a private window.
• No match. The rule does not match the URL. Check the trailing slash, capital letters and any query string.
• The server answered first. Files such as PDFs are often served directly, so WordPress never sees the request. Redirect those in .htaccess or the Nginx config, or delete the file if appropriate.
• Something else redirected it. Another plugin, a theme, or WordPress’s own canonical redirect got there first.

The opposite problem catches people too: a redirect you never created. WordPress sometimes redirects an old post slug on its own, and it guesses at mistyped URLs. If a visitor ends up on an old post, check whether a rule exists at all before you hunt for it. Unexpected redirects that only happen to logged-out mobile visitors arriving from Google are a common malware symptom. Our malware removal guide covers that.

How do you fix “too many redirects”?

A redirect loop means two rules are sending the request back and forth. Chrome shows ERR_TOO_MANY_REDIRECTS, Firefox says “The page isn’t redirecting properly”, and Safari says “Too many redirects occurred”. The fix is to find the pair of rules and remove one. Adding another redirect makes it worse.

These are the usual pairs:

• Cloudflare Flexible SSL plus a server that forces HTTPS. Cloudflare’s docs explain it: in Flexible mode, Cloudflare talks to your server over HTTP, your server redirects to HTTPS, and the request goes round again. Switch to Full or Full (strict) only once the server has a working certificate. The alternative is to remove the server’s HTTPS redirect.
• URL settings that disagree. WP_HOME and WP_SITEURL in wp-config.php override the Site Address and WordPress Address in Settings > General, according to the wp-config.php handbook. One using http and the other https is enough to loop, especially after a migration.
• HTTPS forced in two or three places. An SSL plugin, a caching plugin’s “Force SSL” option, .htaccess and Cloudflare’s Always Use HTTPS can all do the same job. Keep one.
• A pattern that catches its own target. A regex rule for /shop/.* that redirects to /shop/new/ matches its own destination. Anchor the pattern with ^ and make sure the target falls outside it. Never put the same URL in both fields.

Work from the cheapest check to the most invasive one. Try a private window and clear the site’s cookies. Purge every cache. Compare the four URL values. Check the Cloudflare SSL mode. Rename wp-content/plugins to test whether a plugin is responsible, then restore the folder and reactivate plugins one at a time. As a last step, back up .htaccess, rename it, and save Settings > Permalinks to regenerate WordPress’s own rules. Inner pages return 404 until you do. Also, deactivating a plugin does not always remove rules it already wrote to .htaccess.

When to stop and get help: if the loop is in wp-admin and you cannot reach the database or the server files, if you are on Nginx and the rules live in server config, or if redirects appeared without anyone adding them. Ask your host for the first two. The third needs a security cleanup.

Redirecting from your own code

Developers adding a redirect in a theme or plugin should run it on the template_redirect hook, before any output. Redirect after output and you get “headers already sent”. wp_safe_redirect() defaults to a 302, sends unapproved external hosts to the admin URL instead, and does not stop execution. Always follow it with exit:

add_action( 'template_redirect', function () {
    if ( is_page( 'old-services-page' ) ) {
        wp_safe_redirect( home_url( '/services/' ), 301 );
        exit;
    }
} );

Prefer a server-side redirect like this over a timed meta refresh or JavaScript redirect. Those confuse visitors, screen reader users in particular, and search engines read them less reliably.

Frequently asked questions

Does WordPress redirect a changed slug automatically?

Sometimes, for posts. WordPress remembers some old post slugs and forwards them, but you should not rely on it for pages, products, category changes or domain moves. Test the specific old URL after any change, and add an explicit rule if it returns a 404.

Should I redirect all 404s to the homepage?

No. Visitors who wanted something specific land on a page that does not answer them, and Google may treat those redirects as soft 404s. Redirect URLs that have a real replacement, and let the rest return a useful 404 page.

How long should I keep redirects after a migration?

Google advises at least a year where possible. Many site owners keep them permanently because they cost little and old backlinks keep working. If the old domain stops being registered or served, every redirect on it stops too.

Do redirects slow down a site?

Each hop adds a round trip, so chains are what hurt. A single, direct redirect is a small cost and spares visitors a 404. Measure your own pages rather than trusting general figures, because there is little solid data on this.

How do I redirect users after login or checkout?

That is a destination setting, not a URL redirect. Login redirects come from a login plugin or your membership tool. WooCommerce checkout pages come from WooCommerce > Settings > Advanced > Page setup. If checkout sends people somewhere strange, look for a forgotten plugin setting or a stray .htaccess rule before you blame WooCommerce.

Is it safe to use any redirect plugin?

Use a maintained one with a recent update date and a real install base, and remove redirect plugins you no longer use. A redirect plugin can send any visitor anywhere, which makes it attractive to attackers. Keep one tool in charge of redirects so you always know where a rule lives.

The WordPress.org directory lists over 74,000 free plugins, and every one of them installs with the same two clicks. The clicks are rarely where things go wrong. Installs fail because of the server, the account or the file you uploaded. Activation is where a site breaks, because that is when the plugin’s code starts running next to your theme and every other plugin.

This guide covers the four ways to install a plugin, how to read the error when one fails, and what to do if the site breaks after you activate.

Which kind of WordPress site do you have?

Check this first. Most “I can’t install plugins” threads turn out to be about the platform, not the plugin, and each platform has a different fix.

• Self-hosted WordPress (WordPress.org software on your own hosting). Any Administrator can install plugins. Everything in this guide applies.
• WordPress.com. This is a hosted service. Its support documentation says plugins need a paid plan, and some plugins are marked “Not supported”. On a free plan the option is simply not there.
• Multisite. WordPress’s Roles and Capabilities documentation says only the Super Admin can install plugins by default. Site admins don’t see the option. The Super Admin installs from Network Admin → Plugins. People often end up on Multisite by choosing it during setup without meaning to. Our guide to WordPress Multisite installation explains how a network is set up.
• A local install on your own computer. These often ask for FTP details because the web server can’t write to your files. The fix for that is further down.

You also need the Administrator role on a single site. Editors and Authors can’t install plugins. The menu doesn’t show an error. It just leaves the option out.

What to check before you click Install

Thirty seconds on the plugin’s listing saves most of the trouble later. On the Add Plugins screen and the plugin’s directory page, look at:

• Compatibility. WordPress shows whether the plugin is compatible with your version or untested with it. “Tested up to” gives the latest WordPress version the developer has confirmed.
• Last updated and active installations. A plugin that hasn’t been updated in years has probably not been tested against current PHP. The install count is a rough tier, not an exact number.
• The Support tab. Look for recent unanswered reports of fatal errors or conflicts with plugins you already run.
• The changelog and readme. WordPress’s Plugin Handbook describes the changelog as the record of each release. Minimum PHP versions, dependencies and known bugs are usually listed there.

Only install from the official directory or from a developer you trust. A “free” copy of a paid plugin from a download site is the usual way malware gets onto a WordPress site. Install one plugin per job, too. Two SEO plugins or two caching plugins on the same site will conflict.

Then make a way back. Take a backup before you install anything on a site that matters, and use a staging copy for stores and for plugins that change checkout, forms or logins. If you aren’t sure what your backup actually includes, read our explainer on what a backup plugin covers.

Method 1: install from the plugin directory

Use this for any free plugin listed on WordPress.org.

1. In the dashboard, go to Plugins → Add New Plugin. Older versions of WordPress label it Add New.
2. Search for the plugin by name. Check the author on the card, because several plugins often share similar names.
3. Click Install Now and wait while WordPress downloads and unpacks the files.
4. Click Activate. The plugin does nothing until you do.

Method 2: upload a ZIP file

Use this for paid plugins and private plugins that don’t come from the directory.

1. Go to Plugins → Add New Plugin and click Upload Plugin at the top.
2. Choose the plugin’s ZIP file. Don’t extract it first.
3. Click Install Now, then Activate Plugin.

Upload the right ZIP. Marketplace downloads, ThemeForest in particular, often come as one big archive holding documentation, license files and several smaller ZIPs. The plugin is one of the inner ZIPs. If you upload the outer bundle, WordPress replies “No valid plugins were found.” The same error appears if you upload a theme here. Themes go in Appearance → Themes → Add New Theme.

Paid WooCommerce extensions have their own route. WooCommerce’s documentation says automatic installation and updates need the WooCommerce.com Update Manager plugin. A manual ZIP upload works, but the site still has to be connected to your WooCommerce.com account before the extension gets updates and support.

Method 3: upload the folder by SFTP or File Manager

WordPress’s Manage Plugins documentation describes this for cases where the server isn’t set up for automatic installs. In practice you also use it when the upload hits a size limit.

1. Extract the ZIP on your computer.
2. Open the extracted folder and make sure the plugin’s main PHP file sits directly inside it. A folder nested inside a second folder is a common reason WordPress can’t see the plugin.
3. Connect with SFTP, or open your host’s File Manager, and upload the folder to wp-content/plugins/.
4. In the dashboard, go to Plugins → Installed Plugins, find the plugin and click Activate.

Method 4: WP-CLI, for developers

If you have SSH access, one command installs and activates a plugin. It takes a directory slug, a ZIP path or a URL:

wp plugin install contact-form-7 --activate
wp plugin install ./my-plugin.zip --activate

To confirm the result and see versions, run wp plugin list. Our guide to wp plugin list covers the filters.

What a correct result looks like

Go to Plugins → Installed Plugins. The plugin should be listed and show as active, usually with a new menu item or a Settings link. Many plugins do nothing until you finish their setup, so open the settings before you decide it’s broken.

Then open the site in a private window, logged out. Look at the home page and at whatever the plugin affects. Submit a test form, or add a product to the cart and go as far as the checkout. Visitors see the logged-out site, and conflicts often show up only there.

“Installed” doesn’t mean “working”. Google’s structured data documentation says to check a plugin’s markup with the Rich Results Test. A header-and-footer plugin can be active while your tracking tags never fire. If the plugin is supposed to produce output, check the output itself.

Why the install failed, by error message

Read the exact message. Each one points to a different cause:

What you see	Usual cause	Fix
The package could not be installed. No valid plugins were found.	Vendor bundle, theme ZIP or nested folder	Upload the inner plugin ZIP, or install the theme under Appearance
A prompt asking for FTP hostname, username and password	File ownership	Ask the host to fix ownership. Use SFTP in the meantime
Installation failed: Could not create directory	Permissions or ownership on wp-content	Same as above
The uploaded file exceeds the upload_max_filesize directive in php.ini, or a 413 error	Host or PHP upload limit	Upload by SFTP, or ask the host to raise the limit
Destination folder already exists	A leftover folder from an earlier attempt	Rename the old folder and try again
No Add New Plugin button, no error	Role, Multisite or WordPress.com plan	See the platform section above

The FTP prompt means an ownership problem

WordPress’s Updating WordPress documentation says it asks for FTP details when it can’t create files with the correct ownership. You don’t actually need FTP. The web server user doesn’t own your files. The fix is to give ownership to the right user, and which user that is depends on the host, so ask them.

Don’t set folders to 777 to make the prompt go away. WordPress’s Hardening handbook advises keeping write access to a minimum and warns that it is risky on shared hosting. Forum threads also suggest adding FS_METHOD to wp-config.php. Practitioners report it often fails when the underlying ownership is wrong. One wordpress.org case was traced to code a migration plugin had left in wp-config.php, so look there if the permissions seem right.

Upload limits are set by the host

Two PHP settings decide how big an upload can be: upload_max_filesize and post_max_size. The lower of the two wins. Raising memory_limit changes nothing here, and some cheap or free hosts don’t let you change the limits at all. Uploading the extracted folder by SFTP avoids the limit entirely.

A leftover folder blocks a fresh copy

A failed install or update can leave a half-written folder in wp-content/plugins/. WordPress won’t write over it. Rename the folder, for example to plugin-name-old, instead of deleting it, so you still have a copy. Then install again. Reinstalling WordPress does not fix this. A plugin’s settings usually live in the database, so a fresh copy normally picks them up again.

If the site breaks after you activate a plugin

A white screen, a “critical error” message or a broken checkout right after activation almost always means the new plugin. WordPress’s Recovery Mode, added in version 5.2, emails the admin address a link that lets you log in and deactivate the plugin that caused the fatal error.

If the email never arrives, open wp-content/plugins/ by SFTP or File Manager and rename the plugin’s folder. WordPress deactivates a plugin whose folder it can’t find. Our WordPress white screen guide covers the case where you aren’t sure which plugin to blame.

Deactivating gets you back in. It doesn’t tell you what the plugin conflicts with. WooCommerce’s conflict-testing documentation gives a method that works on any site:

1. Work on a staging copy with a backup.
2. Update WordPress, the theme and the plugins.
3. Switch to a default theme and deactivate everything except the new plugin, plus WooCommerce if you run a store.
4. Check whether the problem happens again.
5. Reactivate the other plugins one at a time, testing after each, until the problem comes back.

Don’t do this on a live store, because every step changes what customers see. When you report the problem to the developer, include the plugin and theme versions, your WordPress and PHP versions, and the exact error text. For plugins that activate cleanly but misbehave, see fixing plugins that are not working.

Installing is the first step. Updates are the rest

Each plugin you install has to be updated as long as it stays on the site, and each update can conflict with something just as the first activation could. Read the changelog before you update. Delete plugins you no longer use, because an inactive plugin’s files are still on the server and still need patching. Plugin maintenance is a regular job, not something you do once. If you’d rather not do it yourself, SiteSelf handles plugin updates and cleanup on request from chat and reports what changed and what it checked.

When to stop and get help

Stop and contact your host if the FTP prompt or “Could not create directory” doesn’t go away. Ownership is a server setting, and guessing at permissions can open security holes. Stop if a store’s checkout breaks and you have no staging copy or backup to test against. Get help, too, if one plugin fails on several sites at once, or if a reinstall keeps failing after you have renamed the leftover folder.

Frequently asked questions

What is the difference between installing and activating a plugin?

Installing puts the plugin’s files in wp-content/plugins. Activating tells WordPress to load and run that code. A plugin that is installed but not activated does nothing, and that is the most common reason a “new plugin” seems not to work.

Can I install plugins on a free WordPress.com site?

No. WordPress.com’s support documentation says plugin installation needs a paid plan. Self-hosted WordPress has no such restriction. You can install any plugin your host’s server can run.

Should I install plugins directly on a live site?

For a small, well-known plugin on a simple site, a fresh backup is usually enough. For a store, a membership site, or anything that touches checkout, forms or logins, test on staging first. How careful to be depends on what breaks if it goes wrong.

How many plugins is too many?

There is no fixed number. Plugins that overlap, plugins that are abandoned and plugins you have stopped using cause more trouble than the total does. Two plugins doing the same job is the classic source of conflicts.

My management dashboard says the plugin installed on every site, but it isn’t there. Why?

Bulk tools can report success when the child sites never received the file. In one wordpress.org case, a MainWP dashboard showed 100% across about 40 sites because HTTP Basic Auth on the dashboard site blocked the download. Log in to a child site and check the Plugins screen directly.

Can I update a plugin by uploading a newer ZIP?

Recent WordPress versions detect that the plugin is already installed and offer to replace the current version with the upload. Take a backup first. If a leftover folder blocks the update, rename it and upload again.

Changing a WordPress favicon is a settings task, not a coding one. You upload one square image and WordPress does the rest. Most of the trouble comes afterwards. The dashboard shows the new icon, but the browser tab, a colleague’s laptop or Google’s search results still show the old one.

This guide covers both parts: where the setting is in your version of WordPress, and how to work out why the new icon isn’t showing. For icons inside pages, such as menu icons, social icons and Font Awesome, see our guide to adding and fixing icons in WordPress.

Where is the favicon setting in your WordPress?

WordPress calls the favicon the Site Icon, and its location depends on your WordPress version. WordPress.org’s Create a Favicon documentation puts it under Settings → General from version 6.5 onward. In versions 4.3 to 6.4 it is under Appearance → Customize → Site Identity. Many older tutorials and AI summaries still describe only the Customizer route, which is why people end up looking for a menu that isn’t on their screen.

Check two things before you start. Your WordPress version is shown in the Dashboard’s At a Glance box and on Dashboard → Updates. Your theme type matters too. If the Appearance menu shows Editor and no Customize, you have a block theme, such as Twenty Twenty-Four. Our guide to editing your WordPress homepage explains how to tell block and classic themes apart.

Your setup	Where the Site Icon is set
WordPress 6.5 or later, any theme	Settings → General → Site Icon
WordPress 4.3 to 6.4	Appearance → Customize → Site Identity → Site Icon
Block theme (alternative route)	Appearance → Editor → Site Logo block → “Use as site icon”
Older or specialist themes	Sometimes a separate favicon field in the theme’s own options panel

Changing your header logo does not change your favicon. They are separate settings. The only place WordPress ties them together is the block-theme toggle covered below.

How to change the favicon, step by step

You need an administrator account and one image. WordPress.org recommends a square image of at least 512 × 512 pixels, preferably a PNG. If your logo includes small text, use the symbol or a single letter instead, because fine lettering turns to noise at tab size. You don’t need to make a favicon.ico file or edit a theme template. WordPress creates the smaller sizes and adds the tags to the page head.

On WordPress 6.5 and later

1. Go to Settings → General.
2. Find the Site Icon field and click to choose an image.
3. Upload your square PNG, or pick one from the Media Library.
4. If WordPress asks you to crop, keep the mark centred and leave some space around it.
5. Scroll down and click Save Changes.

Uploading an image to the Media Library does not make it the Site Icon. Only the image chosen in this field is used.

On WordPress 4.3 to 6.4

Go to Appearance → Customize → Site Identity, click Select site icon, upload or choose the image, crop it if asked, and click Publish. Some themes hide or rename this panel. If yours does, check the theme’s documentation before you consider code.

On a block theme, from the Site Logo block

WordPress.org’s Site Editor guide describes another route. Open Appearance → Editor, select the Site Logo block in your header, turn on Use as site icon in the block settings, and save. This makes your full logo the favicon as well. Many logos look poor at 16 pixels, so if you want a simpler mark for the tab, set it in Settings → General instead.

What a correct result looks like

Open your site in a private window. The new icon should appear in the tab. To check the HTML, view the page source (Ctrl+U or Cmd+Option+U) and search for rel="icon". On a Site Icon setup, the tags point to files in /wp-content/uploads/ whose names usually start with cropped-, in several sizes. Each of those URLs should open your new image.

If you see that, WordPress has done its job. Anything still wrong is happening in a browser, a cache or Google, not in your settings.

Why does the old favicon still show?

The causes below are listed roughly by how often people report them. Check them in this order, and use the private-window test to decide where to look. Assuming it is “just cache” every time is how a ten-minute fix turns into a weekend.

Your browser kept the old icon

Browsers cache favicons more aggressively than most page files, and an open tab may never request the icon again. If the private window shows the new icon and your normal window doesn’t, the site is fine. Stop changing settings. Hard-refresh, close and reopen the tab, or clear that browser’s cached images. Bookmarks and phone home-screen shortcuts can keep the old icon for longer.

A cache on the site is serving old HTML

If the private window also shows the old icon, check whether the page source points to the new file. If it still points to the old URL, the HTML is being served from a cache. Clear the layers in order: your caching plugin, then your host’s server cache, then any CDN in front of the site. Each one is cleared separately. Kinsta’s docs, for example, keep server, CDN and edge caching in the MyKinsta dashboard, apart from any plugin cache. Our guide to theme customization that survives updates covers the same cache order for theme changes.

Something else is supplying an icon

If the source shows two sets of icon tags, or the tags point somewhere other than /wp-content/uploads/, another component is adding its own. Common sources are:

• a theme options panel with its own favicon field
• a page builder (a WordPress.com forum user found that Thrive Architect was overriding the Site Icon, and setting the favicon inside Thrive fixed it)
• a favicon or SEO plugin
• tags pasted into a header-and-footer code plugin or header.php
• a favicon.ico left in the site root by a host or an earlier setup

The root file catches many people. One r/Wordpress user spent hours trying to get rid of HostGator’s default favicon.ico. To check for one, visit yourdomain.com/favicon.ico. If an old icon loads, delete the file or replace it, which needs file or hosting access.

The sources don’t agree on which tag a browser picks when there are several, so don’t count on one winning. Choose one method to control the icon and remove the others. Adding another manual tag on top usually makes the problem worse, as developers pointed out in an r/webdev thread on favicon tags.

The file WordPress points to doesn’t exist

This one is rare. In a WordPress.org support thread, the admin showed the icon, but the live site linked to a generated file under /wp-content/uploads/ that returned a 404. To test for this, open each icon URL from the page source, or run curl -I on it and check for a 200 status. If you get a 404, remove the Site Icon, save, and upload the image again. That fixes most cases. Linking straight to an existing PNG with a manual tag also works, but WordPress stops managing the icon after that.

Why does Google still show the old favicon?

Google search results don’t preview your browser tab. Google picks up favicons on its own crawl schedule. Its favicon documentation requires a <link rel="icon"> in the homepage head, and Googlebot and Googlebot-Image must be able to crawl both the homepage and the icon. The icon needs a stable URL and must be square, at least 8 × 8 pixels, with more than 48 × 48 recommended. Google allows one favicon per hostname and says showing it isn’t guaranteed. A 512-pixel Site Icon meets all of these requirements.

Google also says updates can take several days to several weeks. In Search Console, use URL Inspection to request indexing of the homepage once. Google’s recrawl guidance says repeated requests for the same URL don’t make crawling faster. Threads on Reddit describe owners asking two or three times and still waiting more than two weeks. If you manage a client site, tell the client about the wait before they spot it themselves.

When do you need more than the Site Icon?

The core Site Icon gives you one icon, front end only, with no dark-mode variant. That’s enough for most sites. A plugin makes sense for a specific need. Favicon by RealFaviconGenerator creates full icon sets for desktop browsers, iPhone, iPad and Android. Custom Favicon covers admin dashboard icons, SVG icons and dark mode, but its WordPress.org listing warns that it hasn’t been tested with the latest three major WordPress releases. Whichever you choose, let one method control the icon.

The manual method still works: upload icon files to the site root, usually public_html, and add a head tag. SiteGround’s guide warns that edits to theme files can be lost when the theme updates, so put any tag in a child theme. Use this only when nothing else works.

When to stop and get help

Get help if the page source shows icon tags you can’t trace to any setting, if the fix needs access to the server’s root folder, or if a builder owns your header and you don’t know where it stores the favicon. Also ask whether hours of contractor time make sense. One r/woocommerce owner was billed three hours for a set of small changes that included a favicon, and a commenter estimated about 30 minutes. If the favicon is one part of a larger rebrand you’d rather hand off, SiteSelf handles that kind of work through chat. See our page on design changes to your existing site.

Frequently asked questions

Do I need a favicon.ico file?

Not if you use the built-in Site Icon. WordPress generates PNG sizes and the tags. A root favicon.ico mostly matters for manual setups and for some feed readers and apps that request it directly. An old one left in the root can cause a conflict.

Why did changing my logo not change the favicon?

They are separate settings. Set the Site Icon in Settings → General, or on a block theme turn on “Use as site icon” on the Site Logo block if you want the logo to double as the favicon.

Why can’t I find Appearance → Customize?

Block themes such as Twenty Twenty-Four don’t show the Customizer the same way. On WordPress 6.5 or later, use Settings → General, which is there whatever theme you use.

Can I change the favicon without a plugin?

Yes. The Site Icon has been part of WordPress core since version 4.3 and needs no plugin or code. Plugins are only worth adding for extras like admin icons, dark-mode variants or full multi-device sets.

Can the WordPress admin and login screens use my icon?

The core Site Icon is for the public site. Branding the dashboard needs a plugin that supports admin icons, such as Custom Favicon. Check its compatibility warning on WordPress.org before you install it.

“Icon in WordPress” covers several unrelated jobs, and most bad advice comes from mixing them up. Each one has its own setting and its own ways of breaking:

• Site icon (favicon): the small square shown in browser tabs, bookmarks and Google results. Core WordPress handles it.
• Content icons: icons in menus, buttons, lists and social links. These come from a block, a plugin, your theme or Font Awesome.
• Dashicons: the icon font used inside wp-admin.
• Registered SVG icons: a developer feature that arrived with WordPress 7.1.

Work out which one you mean first. The rest of this guide follows that order.

How do you set the site icon in WordPress?

Upload a square image in the Site Icon field and save. You don’t need a plugin, and you don’t need to create a favicon.ico file. WordPress.org’s documentation recommends a square image of at least 512 x 512 pixels, with PNG as the preferred format.

Where the field lives depends on your version, so check which WordPress version you run before you follow a tutorial. Many older guides still point at the Customizer.

1. Prepare a square image of at least 512 x 512 pixels. Put a simple mark in the centre and leave space around it. Words and fine lines become unreadable at 16 pixels.
2. On WordPress 6.5 or later, go to Settings > General and click Choose a Site Icon. On WordPress 4.3 to 6.4, go to Appearance > Customize > Site Identity and click Select Image.
3. Upload the image and confirm the crop if WordPress asks for one.
4. Click Save Changes (or Publish in the Customizer). Choosing an image without saving leaves the old icon in place.
5. Open the site in a private window and look at the tab.

The General Settings screen provides a dedicated Site Icon option to upload and set your favicon directly without opening the Customizer. · Source: www.hostgator.com

WordPress asks for 512 pixels because it builds the smaller sizes that tabs, bookmarks and home-screen shortcuts need from that one image. The browser tab never shows a 512-pixel icon. Google’s minimum of 8 x 8 pixels is a separate rule for search results, so the two numbers don’t contradict each other.

The site icon and the site logo are separate settings. WordPress.org’s Site Logo block documentation explains that the logo appears on your pages and the site icon appears in the browser. Changing the logo or a featured image does nothing to the tab. WooCommerce’s Storefront theme keeps them apart too: both sit under Customizer > Site Identity as separate fields, and there is no separate “WooCommerce favicon” setting.

Why does the old favicon still show after you change it?

Usually a cache is still serving the old version. Check the URL first, though, because clearing a cache won’t fix a broken file. Work through these checks in order:

1. Confirm the change saved. Reload Settings > General and make sure the new image is in the field.
2. Read what the page actually outputs. View the page source of your homepage and search for rel="icon". Open the URL in its href in a new tab. You should see your image. If you get a 404, a blank page or your homepage, the file is the problem, not the cache.
3. Look for a second source. A favicon plugin, the theme or a hard-coded line in header.php can output its own icon that competes with core. And if a favicon plugin was supplying the markup and you deactivate it, the icon disappears with it.
4. Purge each cache layer. Clear the caching plugin, then the host’s cache, then the CDN, then reload in a private window. On Bluehost, for example, the host cache is under Websites > Manage Site > Performance > Clear all cache.
5. Wait out the browser. Browsers keep their own favicon cache. If the source already points at the new file, a stubborn old tab icon is only a local display problem.

A WordPress.org support thread from June 2026 shows why step 2 comes before step 4. The icon showed correctly in the admin but not on the live site, and the poster had already tried every cache. The cropped image file the markup pointed at didn’t exist. The same order applies to any change that doesn’t appear. Our guide to why a WordPress change isn’t showing walks through the cache layers in more detail.

Why doesn’t Google show your favicon in search results?

Google has its own rules and its own timing. Google Search Central’s favicon documentation asks for the following:

• A <link rel="icon"> tag on the homepage.
• Permission for Googlebot to crawl the homepage, and for Googlebot-Image to crawl the icon file.
• A square image of at least 8 x 8 pixels. Google recommends larger than 48 x 48.
• A URL that doesn’t keep changing.

After that, Google has to recrawl the homepage, which it says can take days to weeks. You can ask for a recrawl with the URL Inspection tool in Search Console. Google also says that meeting the rules doesn’t guarantee the icon will appear.

WordPress’s Site Icon output meets these rules by default. The usual problems are a robots.txt rule or security plugin that blocks the image, or an icon swapped repeatedly while you wait. Each new upload gets a new URL, which works against Google’s request for a stable one.

How do you add icons to pages and menus?

Use the smallest tool that does the job. For social profile links, core WordPress has a Social Icons block. Add it from the block inserter, pick each network, and paste the profile URL.

For general icons in the block editor, search the inserter for “Icon”. Depending on your version and theme, a core block may appear. If it doesn’t, The Icon Block plugin adds a single block containing the WordPress icon library of 290+ SVG icons, and it also accepts your own SVG.

For icons beside classic menu items, the Menu Icons by Themeisle plugin adds an icon picker to Appearance > Menus. It supports Font Awesome, Dashicons and image icons. On a block theme, open the Navigation block in the Site Editor and select an individual item to see which visual options your theme offers.

Two judgments save trouble later. An icon should support a label, not replace it: a phone icon next to “Contact” helps, but a phone icon on its own makes visitors guess. And pick one icon library for the whole site. A Font Awesome set in the menu, a builder’s set in the footer and Dashicons in a widget look inconsistent, and each extra library is another thing that can break after an update.

Why do Font Awesome icons show as blank squares?

The icon font is either not loading or not matching the markup. Font Awesome failures rarely produce an error message. You see empty boxes, question marks, the wrong symbol, or some icons working while others don’t. These causes, ranked by how often they come up in support forums (a rough ranking, not a measurement), cover most cases.

1. A stale cache after an update

The theme or plugin updated, but cached CSS still points at the old font files. Purge every cache layer. If you use a page builder, regenerate its CSS too. In Elementor that is under the plugin’s Tools screen.

2. Two versions loaded at once

The theme loads one Font Awesome version and a plugin loads another, and the incomplete stylesheet wins. In one WordPress.org thread, an events plugin’s Font Awesome stylesheet overrode the Avada theme’s. Installing a third Font Awesome loader makes this worse. Find out which stylesheets actually load, keep one, and use the conflict detection in the official Font Awesome plugin to find the others.

3. Missing font files

This is common after a migration. Open DevTools (F12), go to the Network tab, reload, and filter for woff. A 404 on a .woff2, .woff, .ttf or .eot file means the path is wrong or the file didn’t make the move.

4. Markup that doesn’t match the loaded version

Font Awesome changed its class prefixes between versions 4, 5 and 6, so old markup can point at icons that no longer exist under that name. When the Elementor icon problem in a WordPress.org thread came up, support suggested regenerating CSS, clearing caches and turning on Load Font Awesome 4 Support. Also check that the icon is in your edition: a Pro icon won’t render on the Free set.

5. CORS, MIME type or HTTPS blocking

Fonts served from a CDN need a CORS header. WP Rocket’s documentation lists the console error to look for: “Access to Font has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.” A message saying the header “contains multiple values” means the rule was added in two places. Fixing either one means editing .htaccess or the NGINX configuration.

6. A builder or theme setting

Builders have their own icon-loading options. Elegant Themes’ guide to fixing broken icons in Divi points at its Dynamic Icons setting, and Elementor has options for how it loads icon assets.

Change one thing at a time and recheck. If you change five things and the icons return, you won’t know which change fixed it. Practitioners also warn against site-wide fixes such as a global font rule. Other icons depend on the font settings you would be overriding, so target the broken element instead. If an update triggered the problem, rolling the plugin back is a reasonable stopgap until a fixed release ships. Our guide to plugins that stop working covers that process.

Should you use Dashicons or SVG on the front end?

Keep Dashicons in the admin. WordPress’s developer resources describe Dashicons as the official icon font of the admin since 3.8, and the project no longer accepts icon requests. Developers still use it for custom post type menu icons, but it won’t gain new symbols for your public pages.

For new front-end work, SVG is where WordPress is heading. WordPress 7.1, scheduled for August 19, 2026, adds a public Icon Registration API. Justin Tadlock’s hands-on tutorial on the WordPress Developer Blog shows a developer registering an SVG collection once and using it from PHP, the REST API and the editor. Most site owners will see this indirectly, as themes and plugins adopt it.

WordPress doesn’t accept SVG uploads by default, for good reason: an SVG file can carry script. Keep sanitisation on. Use a plugin or the core API that cleans SVG markup rather than switching off the restriction site-wide.

How do you make icons accessible?

Accessibility rules apply to content icons, not to the favicon. There are two cases:

• An icon next to a text label is decorative. Hide it from screen readers so the label isn’t announced twice.
• An icon with no text label is the control itself. Give the link or button an accessible name that describes the action. W3C’s ARIA Authoring Practices Guide covers how names are calculated.

<a href="/cart/" aria-label="View cart">
  <svg aria-hidden="true" focusable="false">...</svg>
</a>

<img src="divider-star.png" alt="">

W3C’s images tutorial says a purely decorative image should have an empty alt="". Leave the attribute out entirely and some screen readers read the file name aloud instead. Font Awesome’s accessibility documentation explains how its own markup hides decorative icons with aria-hidden="true", which matters when a theme outputs Font Awesome for you.

When should you stop and get help?

The site icon, block icons and cache purges are owner-level work. Hand the job off when the fix moves into territory where a mistake breaks more than one icon:

• CORS headers or MIME types in server configuration.
• Font files lost in a migration.
• Untangling two Font Awesome versions loaded by a theme and a plugin.
• Template work, such as showing icons in place of WooCommerce attribute names. Practitioners on r/woocommerce pointed to Advanced Custom Fields plus child-theme template edits for that one. No setting does it.

Before you change templates, read up on theme customization that survives updates.

If you would rather describe the icon problem than trace it yourself, SiteSelf takes design changes on your existing site through chat. It needs hosting (SSH) access for theme and font-file fixes, and it refuses pages owned by Elementor, Divi or Beaver Builder and tells you why.

Frequently asked questions

Do I need a favicon plugin?

Not for a standard favicon. Core WordPress has handled the site icon since 4.3. A plugin only helps if you want a hand-tuned set for every platform, and then it has to stay active, because its markup goes when the plugin goes.

Can I use my logo as the site icon?

Yes, if it reads at 16 pixels. A wide logo with a company name usually doesn’t. Crop to the symbol alone or make a simplified square version.

Why does my icon look blurry in the tab?

The source image is too small or too detailed. Upload at least 512 x 512 pixels and simplify the design so it survives being scaled down.

Why do some Font Awesome icons work and others don’t?

That pattern points at a version mismatch. Either two versions are loaded, or your markup uses icon names or prefixes from a different version than the one loading. Check the Elements tab in DevTools to see which classes the broken icons use.

Can I upload an SVG as my site icon?

WordPress blocks SVG uploads by default, so use a PNG for the site icon. A PNG at 512 x 512 meets both WordPress’s and Google’s requirements.

Are free icon sets safe to use commercially?

Check the licence of each set. Some free icons need attribution or restrict commercial use. Font Awesome Free and the WordPress icon library publish their licence terms.

Clients often want to see a page before it goes live. A printer needs to check the new menu, a client needs to approve a gallery, or a partner needs to read a draft announcement. WordPress has a built-in setting for this. It needs no plugin and no user accounts, and it takes about a minute.

It also does less than most people expect. The password covers the page’s main content. It doesn’t cover the files on the page, and it doesn’t record who got in. Most “it doesn’t work” reports come from caching, not from the setting itself. This guide covers the steps, how to check the result, what stays exposed, and how to fix it when the right password fails.

Password protected or private: which one do you need?

Choose Password protected when the people who need access don’t have accounts on your site. Choose Private when only logged-in staff should see the page. The WordPress.org support handbook says Private pages are visible only to logged-in users with the Administrator or Editor role. A password-protected page is visible to anyone who has the password.

Both options keep the page out of normal view. As our guide to adding pages in WordPress explains, they also keep it out of menus and the homepage selector. That is fine for a client preview. It can surprise you on a page you meant to link from the navigation.

How to password protect a page in the block editor

You need an account that can edit and publish the page, usually Editor or Administrator. Content access is all this task needs. You don’t need hosting or FTP access.

1. Go to Pages, then All Pages, and open the page in the editor.
2. If the right-hand sidebar is hidden, click the Settings icon in the top bar. Select the Page tab, not the Block tab.
3. Click the Status control. On older versions it is labelled Visibility: Public.
4. Choose Password protected. Some versions show it as a checkbox below the status options.
5. Type the password in the field that appears.
6. Click Update, or Publish if the page is new. The setting doesn’t apply until you save.

There are two other routes. On the Pages list, hover over the title, click Quick Edit, fill in the Password field and click Update. In the Classic Editor, the same control sits in the Publish box as Visibility: Public with an Edit link next to it.

A few mistakes come up again and again. People tick Private by mistake, close the editor without clicking Update, or set the password on the wrong page in a set of similar drafts. A WordPress.org support thread notes that if the option is missing completely, a theme or plugin has probably changed the editor. To check, test with a default theme.

If you’d rather not do this yourself, SiteSelf can set page visibility through chat. It uses the connector plugin’s access, then fetches the page and reports whether the password prompt appears. Pages owned by a visual page builder are refused, and the reason is given.

What a correct result looks like

A logged-out visitor should see your theme’s header and footer, the page title, and a password form where the content would normally be. After the right password, the full content loads. After a wrong one, current versions of WordPress show an error message on the form.

Test in a private or incognito window that has never opened the page. Two things can give you a false result in your normal browser:

• You’re logged in. Testing as an admin doesn’t show you what a visitor sees.
• The cookie. WordPress’s documentation says that after a correct entry, the browser stores a cookie. Visitors who return don’t have to type the password again. Your own browser may skip the prompt and make it look as if protection failed.

The cookie has one more effect. WordPress remembers one post password at a time. Pages that share a password unlock together. Pages with different passwords ask again when the visitor moves between them. A shared password across a set of client pages is convenient. It also means anyone with one link and the password can read all of those pages.

What the password does not protect

The setting hides the page’s main content from people who don’t have the password. Several things sit outside that.

Images, PDFs and other uploads

Files in the media library have their own URLs. Anyone with a file’s URL can still open it, and search engines can still index it. The plugin page for PPWP, one of the main protection plugins, says its page protection doesn’t cover uploaded files either. If a file is the confidential part, protect the file itself. Restrict direct access on the server or move the file to protected storage. Our guide to embedding PDFs in WordPress explains why hiding a download button protects nothing.

Custom fields and custom templates

WordPress’s documentation warns that custom field data isn’t protected automatically. WordPress hides what the_content() outputs. Content from ACF fields, a custom loop, or a template that prints post data directly can still show up under the password form. Wrap that output in a post_password_required() check:

<?php if ( ! post_password_required() ) : ?>
    <?php echo esc_html( get_post_meta( get_the_ID(), 'client_notes', true ) ); ?>
<?php endif; ?>

To find a leak, view the protected page logged out and read everything below the form. Anything you can read there is coming from a template or a field, not from the page content.

WooCommerce catalog listings

WooCommerce’s documentation says a password-protected product still appears in the catalog. Only the single product page asks for the password. To hide the product from the shop, category pages and search results, open the product. In the Publish box, click Edit next to Catalog visibility, choose Hidden, and update the product. Catalog visibility can also be changed for many products at once with Bulk Edit.

Search listings

A password hides the content. It doesn’t tell search engines to drop the page. The URL and title of a protected page can still appear in search results, and files linked from the page can be indexed separately. If the page shouldn’t be found at all, set it to noindex in your SEO plugin as well. Don’t count on robots.txt to keep it out of results.

Why the correct password does not work

The causes below are ranked by how often they come up in support threads and forums. The ranking reflects how often each cause appears in reports. It is not a measured failure rate.

1. A cache is serving the password form

Signs: the right password reloads the form, it works on the second try, or it works for some people and not others. A page cache, server cache or CDN has saved the locked version of the page and keeps serving it. In a 2023 WordPress.org thread, the fix was to clear the cache and exclude the page from LiteSpeed Cache. A 2025 r/Wordpress post reported the same problem with LiteSpeed Cache on OpenLiteSpeed. WP Super Cache has a GitHub issue on the same symptom.

1. Purge every layer: the caching plugin, the host’s server cache, then the CDN (Cloudflare or your host’s edge cache).
2. Exclude the protected page’s URL from page caching. Use your caching plugin’s “never cache” URL list, or ask your host to add the exclusion.
3. Retest logged out in a new private window. Check both that the password opens the page and that a fresh window still shows the form.

Step 3 needs both checks. In the LiteSpeed thread, changing the cache rules led to the page apparently skipping the password altogether. There’s also a cost: excluded pages load without the cache. One user with a gallery of more than 150 images found it slower and accepted that. If you use a protection plugin, follow that plugin’s own cache instructions. PPWP, for example, documents its own cookie names. Those names don’t apply to core or to other plugins.

2. You are testing in a browser that is already unlocked

If the page never asks for the password, check whether you’re logged in, or whether this browser has already entered the password. A private window, a different browser, or clearing the site’s cookies settles it. Browser extensions that block cookies can also stop the password from being remembered.

3. A blank page or the homepage after the right password

The password form sends the visitor to wp-login.php?action=postpass, which should then send them back to the page. Before WordPress 6.8, that return trip depended on the browser’s referrer. A Referrer-Policy: no-referrer header from a security plugin or server config could leave visitors on a blank screen. In a 2024 Bricks Builder forum case, the blank screen was /wp-admin/?action=postpass. The cause was a no-referrer policy, not the builder.

WordPress 6.8 added a hidden redirect_to field to the password form so the return no longer depends on the referrer. Check your WordPress version first. Updating core is the lasting fix. On one older install in a WordPress.org thread, changing the header to strict-origin-when-cross-origin fixed it. If you change the header instead, test anything else on the site that relies on referrers.

4. Theme code or a plugin is interfering

Injected code can break the form or the redirect. In a 2020 GeneratePress forum case, the cause was a Google Analytics hook added through the GP Premium Elements module. Switching themes didn’t help, because the module stayed active. The GoDaddy server cache also hid the result of each test until it was flushed by hand. Content-restriction plugins can also catch the request and send visitors to the homepage. In a 2023 case, a Profile Builder update fixed that.

To isolate the cause, switch to a default theme, then turn plugins off one at a time. Purge the cache between every test. Without the purge you’re testing a stale copy. Our guide to fixing plugins that are not working walks through the full conflict test.

When to stop and get help

Ask your host or a developer when any of these is true:

• The problem survives a default theme, all plugins turned off, and a full purge.
• You can’t see or change the server-level cache.
• You’d need to edit template files to stop a leak.

Give them the page URL, your WordPress version, your caching plugin, your host, and the exact screen or URL a visitor ends up on.

When a shared password is the wrong tool

A page password is light privacy for low-stakes content. One password goes to everyone, so you can’t remove one person without changing it for all of them. You also can’t tell who opened the page or passed the password on. Practitioners on r/Wordpress are blunt about it: it isn’t a way to share confidential documents securely.

• A whole-site lock, several passwords on one page, or protection for part of a page: you need a plugin. Password Protected and PPWP – Password Protect Pages both add these. Every plugin also adds its own updates and cache rules to maintain.
• Each person needs their own login, access is paid, or access must expire: use WordPress user accounts and roles, or a membership plugin.
• Personal data or work under NDA: don’t put it behind a shared password. Having a password doesn’t give anyone permission to share confidential client work.

A password set by your host is a different feature. It locks the whole site at the server, and some hosts say their site lock doesn’t work with their CDN or edge caching. It doesn’t fix a problem with one page’s password.

How to remove protection or replace a forgotten password

To remove the gate, open the page, set the status or visibility back to Public, and click Update. Then purge your caches. Otherwise visitors may keep getting the old password screen.

If you forgot the password but can still edit the page, just type a new one in the same field and save. Then send the new password only to the people who still need access. Everyone using the old one is locked out.

If you have server access but can’t log in, WordPress stores the page password in plain text in the post_password column of the wp_posts table. With WP-CLI, wp post update 123 --post_password='new-password' sets a new one, where 123 is the page ID. An empty value removes the password. Take a backup before you change the database.

Frequently asked questions

Do I need a plugin to password protect a page?

No. Per-page and per-post passwords are built into WordPress and cost nothing. You only need a plugin for a site-wide lock, part of a page, more than one password per page, or protection by category or product.

Can one password unlock several pages?

Yes. Give the pages the same password. The browser’s cookie remembers it, so the visitor enters it once and the other pages open too. That convenience also widens access, so use it only when everyone should see every page.

Can each client have their own username and password?

Not with page passwords, which use one shared password for each page. Create WordPress user accounts with a suitable role, or use a membership or content-restriction plugin that links pages to accounts.

Why doesn’t it ask me for the password anymore?

Your browser already holds the cookie from an earlier entry, or you’re logged in. Open the page in a private window to see what a new visitor sees.

Can I password protect my blog’s posts page?

The page you set as the Posts page under Settings, then Reading, shows a list of posts rather than its own content. The page password may not work the way it does on a normal page. Protect the individual posts, or use a plugin that protects categories.

Does a password-protected page still appear in Google?

It can. The content is hidden, but the URL and title can still be listed, and images or PDFs linked from it can be indexed on their own. Add a noindex tag if the page shouldn’t appear in search, and protect sensitive files separately.

You changed a URL, and now the old one returns a 404. Bookmarks, backlinks and Google’s index all still point to the old address. A 301 redirect in .htaccess tells the server to send every request for the old address to the new one, and it tells search engines the move is permanent.

Writing the rule is the easy part. The real risk is the file it lives in, because WordPress keeps its permalink rules there too. A misplaced line can do nothing at all, start a redirect loop or take the whole site down. This guide covers the safe order of work. If you are changing URLs as part of wider search work, our guide to doing SEO on WordPress explains where redirects fit.

Does your server read .htaccess at all?

Check this first. .htaccess is an Apache configuration file. Nginx ignores it. Kinsta’s documentation says its WordPress sites have no .htaccess file and points users to its MyKinsta redirect tools instead. WP Engine has deprecated .htaccess and recommends its own alternatives. On hosts like these, a perfectly valid rule does nothing, and nothing tells you so.

If your host’s control panel or documentation doesn’t say Apache, ask support which web server runs the site and whether it reads .htaccess rewrite rules. This matters most when staging and production run on different hosts: a rule that works on Apache staging can be dead weight on an Nginx production server. If the answer is no, use the host’s redirect tool, a redirect plugin or your CDN’s redirect rules. The patterns below won’t apply.

Where do 301 rules go in a WordPress .htaccess file?

Put them above the # BEGIN WordPress line, never between the BEGIN and END markers. WordPress owns that block and rewrites it whenever you save Settings > Permalinks, so anything you add inside it can disappear. Its last rule is a catch-all that hands every request that isn’t a real file to index.php. A RewriteRule placed below that catch-all may never run.

Before you edit:

1. Open the site root (often public_html) over SFTP or in your host’s file manager. Turn on “Show hidden files”, because names that start with a dot are often hidden. A missing-looking .htaccess is usually just hidden.
2. Download a copy of the file and keep the SFTP connection open, so you can put it back in seconds.
3. Edit in a plain-text editor. Curly quotes pasted from a word processor will break the file.

A working layout looks like this:

# BEGIN Custom redirects
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]
</IfModule>
# END Custom redirects

# BEGIN WordPress
# (WordPress-generated rules, leave untouched)
# END WordPress

Practitioners disagree on one detail. A Webmasters Stack Exchange answer argues that the simpler Redirect directive (mod_alias) is processed by a different module from WordPress’s RewriteRule lines (mod_rewrite), so its position in the file matters differently. The practical answer is to pick one module for your redirects. RewriteRule above the WordPress block is the most predictable choice, and you still test the result.

Which 301 rule fits your move?

Use Redirect for a quick one-off. Use RewriteRule when you need patterns, conditions on the host or protocol, or query strings. Two details catch people out. In .htaccess, Apache strips the leading slash before matching a RewriteRule, so patterns start with ^old-page, not ^/old-page. And literal dots in a pattern need escaping, as in \..

One page

Redirect 301 /old-page/ https://example.com/new-page/

Redirect matches a prefix and adds whatever follows it to the target. That means this rule also sends /old-page/child/ to /new-page/child/. If you want an exact match, use the RewriteRule version from the layout above. Include the trailing slash on the target too, or WordPress adds one with a second redirect.

A whole directory or category

RewriteRule ^category/guides/(.*)$ /resources/$1 [R=301,L]

(.*) captures the rest of the path, and $1 puts it back in the new location. Rules for specific pages that should go somewhere else must sit above this one. Apache works through the rules in order, so a broad rule placed first catches those pages before their own rules get a turn.

Old domain to new domain, keeping paths

RewriteCond %{HTTP_HOST} ^(www\.)?old-example\.com$ [NC]
RewriteRule ^(.*)$ https://new-example.com/$1 [R=301,L]

This works only if the paths stay the same on the new domain. If /shop/product-a/ has become /catalog/product-a/, add specific rules above this one. Keep the old domain registered and pointing at the server, or every one of these redirects stops.

HTTP to HTTPS and www to non-www in one hop

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Separate rules for protocol and host stack into two redirects: http://www goes to https://www, then to https://. This combined rule does it in one response. Add it only after HTTPS works at the host. If the site sits behind a proxy or CDN that handles SSL, the origin may see every request as HTTP, and this rule loops. See the loop section below.

A URL with a query string

RewriteCond %{QUERY_STRING} ^p=123$
RewriteRule ^$ /new-post/ [R=301,L,QSD]

RewriteRule never sees the query string, so you match it with a condition. QSD drops the old ?p=123 from the target, so it isn’t carried over to the new URL.

How do you test a 301 before it sticks?

Write the rule as R=302 first. Apache’s per-directory rewrite guide recommends a temporary redirect while you debug, because browsers cache 301s. A wrong 301 can keep firing in your own browser even after you fix the file. Switch to 301 once every destination checks out.

Test from the command line, not only in a browser:

curl -sIL http://www.example.com/old-page/

This prints each response in order. You want one 301 (or 302 while testing) with the correct Location, then a 200. Check the old URL, the new URL, and the http, https, www and non-www versions of each. If you prefer a browser, use a private window.

Two or more 301s in that output is a chain. Google’s site-move documentation says Googlebot follows up to 10 hops but recommends redirecting straight to the final URL. If a chain can’t be avoided, Google says ideally no more than three hops and fewer than five. Point old rules straight at the final URL, and update your internal links so your own menus and posts skip the redirect entirely.

Check where each redirect lands, too. Google warns that a redirect to an unrelated page, like sending everything to the homepage, can be treated as a soft 404. If a page has no real replacement, a useful custom 404 page serves visitors better than a homepage redirect.

Why is the redirect doing nothing?

These are the common causes, roughly from most to least frequent:

1. The server doesn’t read the file. It runs Nginx, or the host has turned .htaccess off. Ask the host.
2. The rule sits below WordPress’s catch-all. Move it above # BEGIN WordPress.
3. Your browser cached an old response. Test with curl or a private window.
4. The pattern starts with ^/. Remove the slash.
5. A broader rule matched first. Put specific rules above general ones.
6. You edited the wrong file. Hosting accounts with several domains have several document roots, each with its own .htaccess.
7. mod_rewrite or AllowOverride is off. Only the host can change this.

Not every unexpected 301 comes from your file. WordPress issues its own canonical redirects, for example adding a trailing slash, and a redirect plugin may also be acting on the same URL. Pick one place to manage each redirect and check both.

How do you fix “too many redirects”?

Chrome shows ERR_TOO_MANY_REDIRECTS. Firefox says “The page isn’t redirecting properly”. The usual cause is two layers both trying to set the canonical address. WordPress’s Logging In handbook lists mismatched site URL settings, mixed HTTP and HTTPS values, and conflicting SSL or redirect settings at the CDN, proxy, host or server.

Work through the layers in order:

1. Settings > General: WordPress Address and Site Address must match the final URL exactly, protocol and www included. If WP_HOME or WP_SITEURL is set in wp-config.php, those values win.
2. Your .htaccess: comment out your HTTPS and www rules and test again.
3. SSL or redirect plugins: if one already forces HTTPS, remove your rule or switch the plugin’s redirect off. Keep one, not both.
4. The CDN: in Cloudflare, “Flexible” SSL serves HTTPS to visitors but connects to your server over HTTP. An HTTPS rule on the server then sends every request back round in a loop. Cloudflare’s troubleshooting docs cover switching the mode when the server has its own certificate.
5. Reverse proxies: WordPress’s HTTPS handbook warns that loops happen when the proxy terminates SSL and WordPress doesn’t read the X-Forwarded-Proto header.

Clear cookies and caches after each change, or you will be testing an old response.

What if the site returns a 500 after the edit?

A syntax error in .htaccess can stop every request. Upload your backup copy straight away. If you don’t have one, follow WordPress’s Common Errors handbook: rename the file to .htaccess_old, load the site, then go to Settings > Permalinks and click Save Changes to rebuild the default rules. Add your custom rules back one at a time, testing after each. Our guide to fixing a WordPress white screen covers the other causes if renaming the file doesn’t help.

If pretty permalinks then return 404 everywhere except the homepage, the WordPress block is missing or mod_rewrite is off. This is a different problem from a bad 301. Save permalinks again, then ask the host to enable mod_rewrite.

When should you stop and get help?

A handful of rules is a 20-minute job. A site migration is not. If you are moving hundreds of URLs, changing URL case, or consolidating sites, build a spreadsheet that maps each old URL to its closest live replacement first, and test a sample after launch. Get help if a loop persists across the CDN and host, if you can’t read the server error log, or if the whole site is down and the rename didn’t fix it. For WooCommerce product and category URL changes, turn on WooCommerce’s own 301 redirect option before you edit the permalinks. It avoids most of this.

If you’d rather not edit server files at all, SiteSelf can add and check 301 redirects on request through chat. Editing .htaccess needs hosting (SSH) access, and the agent reports what changed and what it checked.

Frequently asked questions

Can I change or remove a 301 later?

Yes. Edit or delete the rule and the server stops sending it. Browsers that already cached the 301 may keep following it for a while, though. That’s why you test with a 302 until the destination is final.

Do I need RewriteEngine On before my rules if WordPress already has it?

Add it to your own block anyway. It costs nothing, and your rules keep working if the WordPress block is removed or rebuilt. Repeating it does no harm.

Should I redirect every 404 to the homepage?

No. Google says redirects to irrelevant pages can be treated as soft 404s, and visitors get confused. Redirect old URLs to their nearest real equivalent, and let pages with no replacement return a proper 404.

Is .htaccess faster than a redirect plugin?

For a normal site with dozens or a few hundred redirects, the difference is too small to drive the decision. Choose by who maintains the redirects. A plugin suits people who don’t want to touch server files. .htaccess suits pattern rules and domain-wide moves on Apache.

Why did my custom rules disappear?

They were inside the WordPress block, or a plugin rewrote the file. Keep custom rules in their own commented section above # BEGIN WordPress. Check the file again after you save permalinks or update security and SSL plugins.

In WordPress, “template” can mean five different things. It can be a block template in the Site Editor, a PHP file in a classic theme, a WooCommerce template override, a page builder layout, or a demo design you imported when you set the site up. Most failed template edits happen in the wrong one of these.

So the job is not “edit the template”. It’s finding the layer that actually draws the page, making the change there, and checking that the change shows up, affects only what you meant, and survives the next update. This guide covers each route. If you want the broader picture of theme work first, see our guide to editing themes without losing work.

Which kind of template is your site using?

Start at Appearance in the dashboard. If you see an Editor item, you have a block theme. If you see Customize and no Editor, you have a classic theme. WordPress.org’s documentation says the Site Editor only appears when a block theme is active. If you’ve been looking for a template editor and can’t find one, this is usually why.

What you see	Theme type	Where templates live
Appearance > Editor	Block theme	Site Editor (saved in the database), plus HTML files in /templates and /parts
Appearance > Customize, no Editor	Classic or hybrid theme	PHP files such as single.php, page.php, header.php
A builder’s own template or theme-building menu	Either type	The builder’s own templates, with display rules
A woocommerce folder in your theme	Either type, store only	Override files that replace WooCommerce’s defaults

Next, work out whether your change is to content, to style or to structure. Six words in a hero is content: edit the page. A new button color everywhere is style: use Styles or Additional CSS. An author box on every post is structure: edit the template.

How to customize a block theme template in the Site Editor

On a block theme, you can change templates without writing code. Every template is shared, though, so check what else uses it before you save.

1. Go to Appearance > Editor > Templates. Open the template that controls the page type you want to change, such as Single Posts, Pages or Archive.
2. Edit the blocks. Headers and footers are template parts. A change to one appears on every page that uses that part.
3. Click Save. WordPress lists everything you’re about to save: templates, template parts, navigation and synced patterns. Read that list. If you see something you didn’t mean to touch, untick it.
4. To change colors, fonts or spacing across the whole site, use Styles instead. Styles keeps revisions, and you can reset it.

How to change the template for one page only

Leave the shared template alone. Someone on the WordPress.org forums edited a template they used for every page, trying to change just one of them, and lost earlier work. The advice they got applies to everyone. Edit that page’s content instead. Or create a new template, assign it to that page in the page’s settings sidebar, and build it from a non-synced pattern. A non-synced pattern is a plain copy, so editing it on one page leaves the others alone.

Why your file edit loses to the Site Editor

WordPress’s Theme Handbook sets the order. WordPress first looks for a template saved in the database through the Site Editor. Then it checks the child theme’s /templates folder, then the parent theme’s. It uses the first one it finds. So if anyone has ever saved that template in the Site Editor, nothing you change in the file over FTP will show.

To make the file count again, reset that template in the Site Editor. A reset deletes the saved version, so export or copy its block markup first. The handbook also notes that templates saved in the database never turn into theme files on their own. If you want a template to ship with the theme, copy its markup into the matching file yourself.

How to customize a classic theme template with a child theme

On a classic theme, templates are PHP files. WordPress picks the most specific file that matches each request. A page with the slug “about”, for example, uses page-about.php if it exists, and page.php if it doesn’t. Never edit the parent theme’s files. The next theme update replaces them, and your changes go with them. Put your changes in a child theme, which a parent update leaves alone. Practitioners report losing work to this mistake more than any other.

1. Back up the site. Ideally, work on a staging copy.
2. Create a folder in wp-content/themes, for example astra-child.
3. Add a style.css with a header. The Template line must match the parent theme’s folder name exactly, including capital letters.
4. Copy only the file you need from the parent into the child, at the same path and with the same filename, and edit the copy.
5. Activate the child theme under Appearance > Themes and check the page.

/*
Theme Name: Astra Child
Template: astra
*/

Your child theme’s stylesheet won’t always load on its own. The handbook says that depends on how the parent theme loads its styles. If your CSS isn’t applying, add this enqueue to the child theme’s functions.php:

add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_style( 'child-style', get_stylesheet_uri() );
} );

To give one page its own layout, create a file in the child theme that starts with <?php /* Template Name: Landing */ ?>. Then pick it from the Template field when you edit the page.

Child themes have limits. A child theme still depends on the parent, and some themes load their files with get_template_directory(). That function always points at the parent theme, so a copy in the child is ignored. The handbook also says a child theme isn’t always the right tool. If your design differs a lot from the parent’s, building a separate theme may be the better choice.

When Additional CSS is all you need

A lot of “template” requests are really styling: padding, a font size, a button color. On the WordPress.org forums, a non-coder who took over a site built by an agency had been installing plugins to adjust spacing. The fix was simpler. They right-clicked the element, chose Inspect to find the CSS rule, and pasted an override into Appearance > Customize > Additional CSS. As support pointed out in that thread, plugins are for adding features, not for CSS tweaks.

Theme updates don’t touch Additional CSS. It can’t change the HTML structure, though. If the element you want doesn’t exist in the page’s markup, you need the template layer. For block themes, the Styles panel is the equivalent place. We cover choosing between these layers in more detail in theme customization that survives updates.

How WooCommerce and page builder templates differ

To override a WooCommerce template on a classic theme, copy the file from wp-content/plugins/woocommerce/templates/ into a woocommerce folder in your child theme. Keep the same path, minus the templates folder. WooCommerce’s template documentation adds two traps. If your theme has a woocommerce.php file, WooCommerce uses that file instead of woocommerce/archive-product.php. And themes with custom templates have to declare WooCommerce support.

Overrides go stale. WooCommerce’s developer docs say your copies don’t update when WooCommerce updates its own templates. WooCommerce > Status > System Status lists your overridden templates and flags outdated ones. The fix is manual: back up your copy, copy the new default into its place, then redo your changes. WooCommerce says a one-click update isn’t practical, because themes are coded too differently. Our guide to updating a theme without losing work adds this check to the update routine.

Some parts of a product page are added by hooks rather than by a template file being loaded directly. In one WordPress.org support thread, copied overrides of price.php and product-image.php did nothing. WooCommerce support suggested removing the woocommerce_template_single_price action and adding a replacement that loads the template with wc_get_template(). Experienced store developers go further: use hooks where you can, and keep your overrides few and small.

On block themes, WooCommerce 10.2 moved its product block templates into the Site Editor, under All Templates > Add Template. Instructions written before September 2025 may point you to the wrong screen.

Page builders keep a template layer of their own. If a builder’s theme-building feature controls your shop or product pages, editing the WooCommerce page or a theme file won’t change them. Edit the builder’s template and check its display conditions.

Why your template change doesn’t show up

Work through these in order. The first two cause most cases.

1. A higher-priority template wins. A version saved in the Site Editor, a woocommerce.php file or a builder template is drawing the page, not the file you edited.
2. A cache is serving the old page. WordPress.org’s FAQ names the browser cache, the server cache and caching plugins. Add your CDN and object cache to that list. In the WooCommerce thread above, the overrides only appeared after the poster cleared the Redis object cache. Purge the caching plugin, the host cache, the object cache and the CDN. Then load the page in a private window.
3. You edited the wrong file or path. WordPress suggests a deliberately obvious test change, such as a block of red text. If it doesn’t appear, you’re editing a file the site doesn’t use.
4. The child theme is misconfigured. Check the Template value and the stylesheet enqueue, and make sure the copied file’s folders match the parent’s.

If the site shows “There has been a critical error on this website,” the change broke PHP. WordPress’s handbook says to check the admin email inbox, turn on debugging and read wp-content/debug.log. The file path in the error message tells you which file to fix or restore.

When to stop and get help

Visual changes in the right editor are well within reach for most site owners. Stop when the work moves into PHP and you don’t have a working backup or a staging copy. Stop too when a WooCommerce override is outdated on a store that’s taking orders, when a hooked template needs replacing, or when you’re switching themes or builders. A switch means rebuilding every post, archive and product template, not reskinning them. If you’d rather describe the change and have it done on your existing site, here is how SiteSelf handles design and template changes.

After any structural change, check two things the old template may have done for you. Can you still tab through the menus with a keyboard, and does every form field still have a label? And does each page still output exactly one canonical tag?

Frequently asked questions

Do I need a child theme to customize a template?

You need one for code changes to a parent theme that still gets updates. For style-only changes, Additional CSS or the Site Editor’s Styles is usually enough. For block template changes made in the Site Editor, the database copy already survives theme updates.

Is it safe to edit templates in the Theme File Editor?

It’s risky. One PHP typo can take the site down, and the editor doesn’t keep a copy of the previous version. If you use it at all, use it on a child theme and keep FTP or hosting file access ready so you can undo the change.

How do I reset a block template to the original?

Open the template in Appearance > Editor > Templates and use its reset or “clear customizations” option. That deletes your saved version and goes back to the theme’s file, so export or copy the markup first if you might want it again.

Why can’t I see the Template option on my page?

On a classic theme, the Template field only appears if the theme or child theme includes at least one custom page template. On a block theme, you may need to create the template in the Site Editor before you can assign it to a page.

Will my template customizations survive a theme switch?

Mostly not. Child theme files belong to the old parent theme. Block templates saved in the Site Editor belong to the old theme. Builder templates go with their builder. Plan a theme switch as a rebuild, on a staging copy.

How do I know which classic template file renders a page?

Use the template hierarchy: WordPress chooses the most specific matching file, such as single-product.php before single.php. To confirm, make a visible test change to the file you think is responsible and load the page.