Category: Explainers

Most WordPress sites don’t get a messy taxonomy all at once. It happens one post at a time. Someone adds a tag for a word that appears in an article, then another, and a few years later the site has hundreds of tags used once and a category list nobody can scan. WordPress never shows an error, so nobody notices until an SEO audit or a Search Console report turns up a long list of nearly empty archive pages.

The difference between the two is simple. Categories are your site’s main sections. Tags are optional labels that connect posts across those sections. The difficult part is that every term you create also becomes a page, and that is what this article covers. It sits alongside our step-by-step guide to doing SEO on WordPress.

What actually separates a category from a tag

Categories can be hierarchical and tags can’t. WordPress’s Theme Handbook describes both as taxonomies, which are ways of grouping posts, but only categories can have parent and child terms. Everything else follows from that one structural difference.

That editor row explains a lot of messy sites. Picking from a category list nudges you to reuse what’s already there. Typing in a tag field makes it just as easy to create a new tag as to reuse an old one, so you end up with “email”, “emails” and “email marketing” as three separate archives.

Learn WordPress compares categories to a book’s table of contents and tags to its index. That comparison works. The table of contents has a few entries and every chapter is in it. The index is long, specific, and each entry is worth having only because it points to more than one page.

When a subject should be a category, and when a tag

Use a category when the subject is a permanent section of the site that a visitor might browse on purpose, the kind of thing you would put in a menu. Use a tag when the subject keeps coming up across several sections and a reader of one of those posts would want the others.

Take a bakery that publishes recipes and business news. “Recipes” and “News” are categories. “Gluten free” is a good tag, because it connects a bread recipe with the announcement of a gluten-free range. Readers can follow their dietary need across both sections. A tag for this spring’s sale is a bad one: nothing will be added to it, so anyone who clicks it reaches a dead end.

Before you create a term, run these checks:

• Will it be used on several posts? If not, leave it out. Single-use tags are the clearest sign of a taxonomy going wrong.
• Does it already exist under another spelling? Search Posts > Tags for singular, plural and synonym forms first.
• Does it repeat a category? WordPress.com’s support guide advises against giving a category and a tag the same name. You would just get two archives listing the same posts.
• Is it a format, not a subject? “Tips” and “guide” describe the kind of article. They don’t tell a reader what it’s about.

WordPress allows more than one category per post, but one is the sensible default. A post filed under four categories has no clear home, and every archive it appears in gets a little less distinct. Use child categories when a real hierarchy exists, not to squeeze in extra labels.

Tags are not keywords. Agency developers on r/Wordpress keep describing the same pattern: clients treat the tag box like the old meta keywords field and type in every phrase they want to rank for. One 2014 thread mentions a site with 20,000 tags. No ranking benefit comes from the label itself. Any benefit comes from the archive page being worth visiting.

Why every new tag is also a new page

WordPress creates an archive page for every category and tag, listing the posts assigned to it. That turns a filing decision into a navigation decision and a search decision. A tag on one post creates a page that only repeats that post’s excerpt. A site with 400 of those has 400 thin pages that crawlers can find.

Think of each archive as a page you are recommending to visitors. Would you link to it from the sidebar of a good article? If yes, it’s earning its place. If you would be embarrassed to link it, the tag probably shouldn’t exist.

The archive is also separate from your real landing pages. A Design service page explains and sells the service. A Design category archive is a date-ordered list of posts. Don’t let the archive replace the service page in your menu just because they share a word. If you want tag and category archives to connect visitors to your best pages, our guide to adding internal links in WordPress covers the editor side.

Should category and tag archives appear in Google?

Decide archive by archive. Don’t decide by taxonomy type. Google publishes no rule about WordPress categories or tags. Yoast’s settings documentation points out that useful taxonomy pages can bring in visitors. A common rule of thumb in practitioner forums is to noindex all tags and index all categories. That’s a reasonable starting point, but it’s a heuristic. Google doesn’t require it.

Keep an archive indexable when it’s distinct and useful: it has enough posts to browse, a clear heading and, ideally, a short introduction in the term description. Keep it out of search results when it’s thin, empty or an exact overlap with another archive. In Yoast SEO, go to Yoast SEO > Settings > Categories & tags, choose the taxonomy, turn off its search visibility and save. Yoast also lets you noindex individual terms, so you can keep a strong tag archive indexed and drop the weak ones.

Use the right tool to keep a page out of Google:

• noindex keeps a page out of search results. Google’s documentation says the page must stay crawlable, because Google has to load the page to see the noindex instruction.
• robots.txt controls crawling, not indexing. Blocking /tag/ there can leave URLs showing in results and hides your noindex from Google.
• Redirects or rel=”canonical” are how Google says to merge duplicates. Its canonicalization guide says Google picks a canonical URL when a site has duplicate content, and it lists redirects and canonical tags as the ways to tell it which one you prefer.

Check your settings before you write copy for archives. On r/woocommerce, one store owner wrote unique text for their tag pages and only later found they had set tag archives to noindex in Yoast. If you suspect tag pages are competing with your main pages, use Search Console’s Performance report: filter to the tag URLs and see which queries they share with your posts before you decide anything.

If you would rather have someone else make the archive indexing changes, write the redirects and check the result, SiteSelf does that kind of SEO settings and redirect work on request through chat.

How to clean up a messy taxonomy without breaking links

Audit first and delete last. Renaming a term’s slug or deleting a term changes or removes an archive URL. Bookmarks, backlinks and Google’s index still point at the old address. Take a backup before you start.

1. Export the lists. In Posts > Categories and Posts > Tags, record each term’s name, slug and post count.
2. Flag the suspects. These are single-use tags, near-duplicates, and tags that copy a category. A low count is a reason to look closer. It doesn’t automatically mean delete.
3. Decide each one. Keep it, merge it into another term, promote it to a category, convert it, or retire it.
4. Merge or convert in bulk. WordPress’s Categories and Tags Converter (Tools > Import) converts selected terms from one taxonomy to the other. The free Term Management Tools plugin adds Merge, Set Parent and Change Taxonomy to the bulk actions on the term screens.
5. Redirect what moved. Send each retired archive URL to its closest replacement with a 301. Don’t send unrelated archives to the homepage. See how a 301 redirect affects SEO for the details.
6. Fix dependencies. Update menus, links inside posts, and any block or template query that names the old term.
7. Test. Load old and new archive URLs while logged out, then watch Search Console for new 404s.

Deleting categories needs one extra check. WordPress’s documentation says deleting a category doesn’t delete its posts. It moves them to the default category, which itself can’t be deleted. So set a sensible default in Settings > Writing first. Otherwise the cleanup quietly fills “Uncategorized”.

A cleanup only lasts if there’s a rule behind it. Practitioners who train clients report that verbal training doesn’t stick. A written one-page policy does better: the approved category list, what each one covers, and “search before you create a tag”. Some agencies go further and turn off tags for clients who keep misusing them.

How WooCommerce product tags differ

WooCommerce has separate taxonomies for products and doesn’t use the post categories and tags. Its documentation describes three tools. Product categories are hierarchical departments such as Dresses or Shoes. Product tags are flat labels that cut across departments, such as “summer” or “gift idea”. Attributes are properties like size, colour or material, which shoppers filter by and which drive variations.

The common mistakes are using tags as main departments and using tags for business logic. A tag can say “Tuesday delivery”, but it won’t enforce a delivery day or an order cutoff. That needs a plugin built for it. Normally a product keeps a single URL however many categories it has, unless your product permalink base includes the category.

Frequently asked questions

Most small sites that add a chat widget find out within a month what they actually needed. Either the same five questions come in every day, or every question is different and needs someone who knows the business. A chatbot is good at the first case and live chat is good at the second. Neither one works if nobody looks after it.

So the useful question is not which one is better. It is which requests software can answer safely, who answers the rest, and how fast that person can take over. Sometimes the honest answer is that visitors only need a reliable way to reach you. In that case a contact form in WordPress may do more than either kind of chat.

What actually separates a chatbot from live chat

With a chatbot, software writes the replies. With live chat, a person types back in real time, usually from a dashboard or a phone app. Most of the confusion comes from treating “chatbot” as one thing, because there are two very different kinds.

A scripted bot follows a decision tree: buttons, fixed questions and fixed answers. It cannot go off script, which makes it predictable and limited. An AI bot writes its own answers, ideally from a knowledge base made of your pages, posts, products and FAQs. It can handle questions nobody planned for. That is its strength and its risk, because it can also answer confidently when it has no idea.

Many WordPress chat plugins now sell both modes in one widget: a bot that answers first and a person behind it. That setup is called hybrid, and it is the pattern most practitioners recommend. There is also a third pattern that often gets counted as live chat. Contact-button launchers show floating icons that open WhatsApp, Messenger or a phone call. That is a shortcut to another channel, not a chat service.

Before you install anything, check where the conversations live. Many plugins sold as “WordPress chatbots” just place a widget for an external service. The conversations, training and settings sit on the vendor’s servers, not in your WordPress database.

WooCommerce stores have one more trap. WooCommerce’s documentation describes the AI Assistant as an admin tool that does not appear on the storefront. The customer-facing chatbot is the separate AI Support Assistant. You have to enable it and give it an AI provider, a knowledge base and product information.

Which questions belong to a bot and which to a person

Decide by request, not by product. Bots do well with routine, documented, low-stakes questions that come up again and again. People are needed when the answer takes judgment, depends on a specific account, involves money, or comes from someone who is upset.

Practitioners on Reddit and wordpress.org agree on one point: the setup most likely to disappoint is a bot that is supposed to replace people completely. It goes wrong as soon as a visitor has a real problem with an order or an account.

Bots handle more chats than they resolve

The Comm100 Live Chat Benchmark Report 2025 looked at accounts that use AI chatbots. In those accounts, bots handled 62.7% of chats in 2023 and 73.8% in 2024. The share the bots actually resolved stayed flat: 46.0%, then 45.8%.

That gap matters more than any other statistic in this debate. Vendors usually advertise “handled” or “deflection” figures. A bot can take part in three quarters of conversations and still finish fewer than half. The rest either reach a person or end without an answer. Keep the source in mind, though. Comm100 sells chat software, and its data comes from its own customers, who mostly run staffed support teams rather than one-person WordPress sites.

Why customer preference surveys seem to disagree

The surveys measure different things, so they are not really in conflict. Salesforce’s State of the AI Connected Customer research, a YouGov survey of 15,015 consumers in 2024, found that 30% would use an AI agent instead of a person to get faster service, and 35% would do so to avoid repeating themselves. Tidio’s 2025 study of 1,300 people, Helpful or Hopeless?, found that about 30% would still wait for a human even with a bot available right away, and more than 11% would pay extra to skip the bot.

Both are vendor studies, and Tidio recruited its respondents through Amazon Mechanical Turk and Hotjar, which is a weaker sample. The practical lesson is the same either way: preference depends on the task and the wait. Someone checking a delivery date wants speed. Someone who was charged twice wants a person.

Handoff only happens if someone configured it

Turning on AI in a chat tool does not mean a person will see the questions the bot could not answer. In hybrid tools, what happens after a failed answer is a setting. The usual options are to transfer the chat to an agent, keep it with the bot, or turn it into a ticket or email. Offline hours often have their own setting. Check both, because the defaults may not match what you assume.

A bot that runs overnight does not solve problems overnight. At best, it collects the details so someone can reply in the morning. Tell the visitor that plainly, and give a time they can expect a reply.

A good handoff has four parts:

• The bot says it does not know instead of guessing.
• The conversation carries over, so the visitor does not have to explain twice.
• The “talk to a person” option is visible from the start, not hidden behind three failed answers.
• Pricing questions and clear buying intent go to a person.

A fallback line can be as simple as: “I can’t sort out a billing problem here. I’ve saved your question and order number, and someone will reply by email by 10 a.m. tomorrow.”

What chat costs is mostly staff time

Chat tools charge in several different ways, so comparing price tags directly tells you little:

• Per agent seat each month. The bill grows with your team.
• Bundles of conversations. The bill grows with your traffic, including spikes you did not plan for.
• Free core with a paid AI add-on.
• A plugin licence plus your own AI API key. The model provider bills you separately for usage.

The bigger cost is people. Live chat needs someone covering the hours the widget promises. A bot needs someone to write, check and update the content it answers from, and to read the conversations where it went wrong. None of the research behind this article compares the total cost of the two. “Bots are cheaper” is an assumption, not a finding.

Where chat goes wrong after it is installed

Live chat that nobody answers

Practitioners say this is worse than having no chat. It tells visitors nobody is there, and you lose the lead. If you cannot cover normal business hours, even shared between a few people, hide the widget when you are offline or switch to a form.

A bot that guesses or loops

The common complaints are bots that guess, send the wrong help article, or keep asking “Did that solve it?” Train the bot only on content you control, set clear limits on what it answers, and judge it by conversations resolved, not conversations handled. A commenter in r/woocommerce warned that a bot that cannot find the right answer in your content is more frustrating than a slow reply.

Too few chats to matter

Small-business threads on Reddit argue both ways. Some site owners report almost no chats after months. Others say a simple capture flow brought in evening and weekend inquiries they would have missed. The deciding factors are traffic, how often the same question comes back, and whether a short flow is enough. Long flows lose people.

More leads, worse leads

Agencies report that bots can bring in more leads than forms, but more of them are unqualified and take time to sort through. One or two qualifying questions based on what your business actually does will filter better than an open text box.

Widgets that get in the way

Google’s guidance on interstitials and dialogs recommends banners over large dialogs, so do not auto-open a full-screen chat. Google renders JavaScript and indexes the rendered HTML. An answer that exists only inside a chat conversation is not page content, so keep the important answers on the page as well. For accessibility, WCAG 2.2’s Focus Not Obscured criterion says an open chat window must not completely hide the control that has keyboard focus. W3C’s suggested fixes are to let content reflow, place the window in unused space, or let Escape close it.

Why the widget shows for you but not for visitors

Usually the cause is caching or JavaScript optimization. Logged-in admins normally skip the page cache, so you see the widget while visitors get an older copy of the page, or a script that loads in the wrong order. An MxChat thread on wordpress.org started exactly like this: the bot appeared for the admin but not for normal visitors. Work through these checks in order:

1. Connection. Confirm the plugin is active and the account or site ID is saved. Use one install method only, either the plugin or pasted code, never both.
2. Display rules. Check desktop and mobile settings, page exclusions, and any option that hides the widget when no agent is online.
3. A clean test. Open a new private window, not one that was already open, and load the page logged out.
4. Each cache layer. Purge the caching plugin, then the host’s server cache, then the CDN. On some hosts, the server purge does not clear the CDN. Why a page is not updating walks through each layer.
5. Script optimization. Turn off delay and defer JavaScript for a moment. If the widget comes back, turn the options on again one at a time, exclude the chat script from the one that breaks it, and update the chat plugin. Do not leave all optimization off for good.
6. The theme. The theme must call wp_footer() before </body>. That is how WordPress prints footer scripts, and many widgets rely on it. A console error like e(...).live is not a function means outdated jQuery code. Updating the theme fixes that. Reinstalling the chat plugin does not.
7. Conflicts. The Health Check plugin’s Troubleshooting Mode turns off plugins and switches the theme only for your logged-in session, so visitors to a live store are not affected.
8. Content Security Policy. If the site sends a CSP header, add the chat vendor’s domains to script-src and frame-src. Do not remove the policy.
9. Works on staging, missing on live. Compare the page source on both, then ask the host about differences in PHP settings.

If none of that finds it, the broader guide to WordPress plugins that are not working covers debug logs and conflict testing. If you would rather hand the problem off, SiteSelf’s WordPress bug-fix work traces it on your live site and reports what it changed. Plugin settings work through the connector plugin. Theme and script fixes need hosting access.

How to decide for your own site

Start with last month’s questions, from your inbox, phone notes and form entries. Sort them into routine and judgment calls. Then name who can answer, and during which hours.

If you are unsure, have a person handle chat for a few hours a day before building a bot. You will learn what visitors actually ask, and that becomes the bot’s first knowledge base. Automate only the questions that keep coming back and already have written answers. Set up handoff for both staffed and offline hours. Then, for the first few weeks, read the conversations the bot did not resolve. Those tell you what to add to your content, and which questions should go straight to a person.

Frequently asked questions

Most people searching for a maintenance mode plugin want one of two things. Some want a holding page up while they change something. Others want to get rid of a maintenance screen they never turned on. These are different problems, and WordPress uses a different mechanism for each.

Start by working out which one you have. The rest of this page covers choosing the right kind of plugin, checking that it tells search engines the right thing, and knowing when maintenance mode is the wrong tool.

What does a maintenance mode plugin do that WordPress doesn’t?

A plugin gives you a holding page you control, and it stays up until you switch it off. WordPress core only has a maintenance state tied to updates. When you update core, a plugin or a theme, WordPress writes a hidden file called .maintenance to the site root. Visitors then see “Briefly unavailable for scheduled maintenance. Check back in a minute.” The updater normally deletes the file when the update ends.

A plugin’s maintenance mode is a saved setting. LightStart’s documentation says its mode is switched on and off manually in the plugin settings. Other plugins work the same way. As a result:

• Deleting .maintenance does not turn off a plugin’s mode.
• Switching a plugin off does not fix a failed update.
• WP-CLI’s wp maintenance-mode activate, deactivate and status commands control core’s maintenance mode, not a plugin’s setting.

You can usually tell them apart by eye. Core shows one plain line of text. A plugin shows a designed page with its own heading, a logo, and sometimes a countdown or a signup form. The 503 response code explained article has a table of which screen comes from which source.

Why is my site stuck if I never installed a maintenance plugin?

An update was interrupted before WordPress could delete .maintenance. Common causes include closing the browser tab, a timeout, low memory or disk space, wrong file permissions, and updating many plugins at once. Kinsta’s documentation lists bulk updates as a risk.

WordPress’s Advanced Administration Handbook gives the fix. First, make sure no update is still running. Then delete .maintenance from the folder that holds wp-config.php, which is often public_html. You can do this with your host’s file manager or over SFTP. The file name starts with a dot, so you may need to turn on “show hidden files.”

Deleting the file only takes the screen down. Your plugin or core files may still be half-updated. Go to Dashboard, then Updates, and run whatever didn’t finish, one item at a time. Our guide to fixing a failed WordPress update covers what to do if the update fails again.

Core treats the file as expired once its timestamp is ten minutes old, according to the wp_is_maintenance_mode() reference. So if the screen lasts for hours, the file may not be the only cause. Common culprits are a cached copy of the 503 page, a site broken by the half-finished update, or a plugin’s own screen.

If the site keeps getting stuck, another plugin may be interfering with the updater. In one WordPress.org support thread, updates stalled again and again, and clearing caches didn’t help. A moderator traced it to a starter-templates plugin that was blocking updates. The fix was to deactivate that plugin, update it, reactivate it, and then update everything else. Retrying the same bulk update without finding the cause just recreates the lock.

Which kind of maintenance plugin fits the job?

Pick the lightest tool that does the job. Plugins in this category range from a single switch to a full page builder, and the extra weight only pays off when you use it. Install bands below are from the WordPress.org directory.

Practitioners in WordPress.org and Reddit threads keep asking for the same three things: a plain switch for update windows, preview access for clients, and the option to use an existing WordPress page as the holding page. The third request usually ends with someone suggesting custom code. Test before you trust any feature list, including the one above. Bypass rules and paid tiers change between versions.

If you are writing the message itself, our coming soon text examples cover the difference between a launch announcement and a notice that the site is down.

Why does the plugin look broken when it isn’t?

Usually there are two reasons: you are logged in, or a cache is serving an old copy.

You are logged in. Administrators bypass the holding page, and on some plugins any logged-in user does. Owners who test while signed in often decide the plugin “won’t publish.” Test in a private window or on another device. Note whether your plugin’s bypass applies to administrators only or to every logged-in account. On a store, every customer who logs in counts as a logged-in user.

A cache is serving the old page. This can be a page cache plugin, your host’s server cache or a CDN. It explains both “I turned it on and nothing happened” and “I turned it off and visitors still see it.” In one resolved WordPress.org thread, the maintenance page stayed up after the plugin was deleted, and there was no .maintenance file. The cause was caching. LightStart’s FAQ advises turning off cache plugins while its mode is on, or clearing the cache after every change. Purge every layer each time you switch the mode on or off.

On LightStart, check the exclusions too. Its documentation says exclusions match parts of URLs, so excluding / matches every page and opens the whole site. If you use a custom login URL, add it to the exclusions, or you may lock yourself out of the login page.

What should the page tell search engines?

Visitors read the page. Search engines read the status code. A page can look like a maintenance notice and still return 200 OK. Search engines then treat it as the site’s real content.

Google Search Central gives specific guidance for closures:

• If the site is fully down for one or two days, return a 503 with a best-effort Retry-After header and show a short, helpful page.
• For longer closures, keep the site online and limit what it does, for example by disabling the cart.
• Don’t block the site in robots.txt, return 403, 404 or 410, or use noindex to signal a temporary closure.

A coming-soon page for a site that has never launched is a different case. It is common practice to serve it with a 200 status so it can be indexed as the real front page. Google’s closure guidance covers existing sites, not pre-launch pages.

Check the response, not the preview. Open your browser’s developer tools, select the Network tab, and load a deep page (not the homepage) while logged out. Or run:

curl -I https://example.com/some-page/

The first line should read HTTP/2 503 (or HTTP/1.1 503). Look for a retry-after line too. LightStart’s changelog includes a fix for a 503 problem in its selected-page mode, which is a good reminder that a correct-looking screen doesn’t prove a correct status.

How do you use maintenance mode around plugin updates?

On a simple brochure site, you often don’t need a plugin. Core already blocks visitors for the few seconds each update takes. On a store, or any site where a half-updated page could take a payment or a booking, use maintenance mode on purpose.

WooCommerce’s update guide sets out the order:

1. Take a current backup.
2. Test the updates on a staging copy first.
3. Put the live store in Coming Soon mode so customers can’t check out while files and the database change.
4. Run updates one at a time and wait for each to finish before refreshing, navigating away or starting the next.
5. Run the WooCommerce database update when you’re prompted.
6. Test the key store workflows: cart, checkout, and the payment method you use most.
7. Reopen. If anything is wrong, keep checkout closed, restore from the backup if needed, and troubleshoot on staging.

Step 7 is the one people skip. When the holding page comes down, all you have confirmed is that it’s gone. Load the checkout as a customer, then clear caches so nobody gets served the maintenance page.

Not everyone wants to run this routine every month. SiteSelf handles plugin and core updates on request through chat: before it starts, it says what is about to change and whether that can be undone, and afterwards it reports what it checked on the live page.

When is maintenance mode the wrong tool?

A maintenance plugin is meant for short, planned pauses that visitors will notice. It doesn’t fit these jobs:

• Weeks of rebuild work. In an r/woocommerce thread, practitioners advised building on staging and going live in a short window. Running a store behind a holding page for weeks risks search visibility. Copying a staging database over the live one can also wipe out orders placed in the meantime.
• A month-long holiday closure. Use catalog mode, a notice, or mark products out of stock. This matches Google’s advice to limit functionality. Replies in the same community strongly advised against pointing DNS somewhere else.
• Keeping a dev site out of Google. “Discourage search engines” relies on robots.txt and isn’t foolproof. A staging site needs real access control.
• Migrations and server-level risk. A plugin only runs once PHP and WordPress have loaded. If the change can break WordPress itself, a static HTML page or a rule on the server is more reliable.

Stop and call your host if the maintenance screen turns into “Error establishing a database connection” or 500-range errors that keep coming back. Learn WordPress’s debugging material for site owners treats those as signs of a wider server problem, not a plugin setting.

Frequently asked questions

A 503 is the one server error that is designed to be sent on purpose. It tells the browser, and Google, “not right now, try again later.” That is very different from “this page is broken” or “this page is gone.” It also says nothing about what caused it, which explains why people often fix the wrong thing.

This article covers what the code means, how to read it, and how to work out which part of a WordPress setup sent it. If your site is down right now and you want the repair steps, our guide on how to fix a 503 error on WordPress goes through them in order.

What does a 503 response code actually say?

It says the server is temporarily unable to handle the request, usually because of overload or maintenance. Section 15.6.4 of RFC 9110, the HTTP semantics standard, defines it this way, and MDN’s 503 reference describes the server as “not ready to handle the request.”

“Temporary” describes what the server intends. It doesn’t mean the problem will clear by itself. An overloaded server may recover when traffic drops. A maintenance setting someone forgot to switch off will keep returning 503 for weeks. The two produce the same number.

The server may add a Retry-After header, given either as a number of seconds or as an HTTP date. When it’s there, the server is estimating how long you should wait. When it’s missing, nobody has given an estimate, and you should treat the 503 like any other server error you need to investigate.

How do you read the 503 instead of the error page?

Look at the response headers. The wording on the page is the least reliable evidence you have. A CDN can put its own branded page in front of an error from your host, and a maintenance plugin can show a friendly holding page that doesn’t return a 503 at all.

In Chrome or Firefox, open Developer Tools, go to the Network tab, reload, and click the first request (the document itself, not an image). Under Headers, note the status code, any Retry-After value, any Server or CDN headers, and the time. From a terminal, this prints the headers of a real GET request:

curl -s -o /dev/null -D - https://example.com/

HTTP/2 503
retry-after: 600
content-type: text/html; charset=utf-8

Plain curl -I also works, but it sends a HEAD request, and some caches and firewalls answer HEAD differently from GET. If the two disagree, trust the GET.

Test while logged out, in a private window or with curl. WordPress maintenance plugins let logged-in administrators through, so the owner sees a normal site while every visitor gets the holding page.

Which part of a WordPress site sent the 503?

There are five usual sources. Where the 503 appears, and when, tells you more than the code does. A 503 on every URL points somewhere different from a 503 that only hits checkout or only appears while you save a post.

Core maintenance is the easiest to recognise

During an update, WordPress puts a .maintenance file in the site root. While that file exists, the core function wp_maintenance() answers every request with a 503 and Retry-After: 600, which asks clients to come back in ten minutes. If the update is interrupted, the file stays and so does the 503. WordPress.org’s troubleshooting FAQ says to delete the file and then run the update again. Deleting the file clears the message. It does not finish the update. Our article on why WordPress updating failed covers that second half.

Resource limits are the most common cause, and the most misread

Nobody publishes data on how often each cause occurs. In support threads, though, the cause reported most often is the host running out of capacity. On most hosts, PHP workers are the processes that build WordPress pages that aren’t cached. When every worker is busy, new requests wait in a queue, time out, and come back as 503s. Cached pages skip the workers completely. That’s why a store’s homepage can look fine while checkout fails, because checkout, cart, login and admin pages are never served from the page cache.

A bigger plan or more memory only helps if you’ve confirmed that a limit is actually being hit. More workers need more RAM and send more simultaneous queries to the same database. If one slow query or plugin is holding workers, more capacity just postpones the next outage. In one WordPress.org WooCommerce support thread, the host said the site needed a VPS. The 503 actually went away when the owner replaced a product-category element on the home page.

Security rules can return 503 to a single action

WooCommerce’s documentation on large data not saving names servers running mod_security, along with PHP’s max_input_vars limit, as reasons why saves of product variations and tax rates fail. If the 503 only appears on one form or one admin action, look for the rule that matched that request. Don’t switch the firewall off. Ask the host for a targeted allow rule instead.

A CDN usually relays the 503 rather than causing it

If the error page carries a CDN’s logo or a request ID, that only proves the request went through the CDN. Most CDN-delivered 5xx errors start at the origin server. Bypass the CDN (most offer a development or pause mode) and request the same URL again. If the 503 disappears, the CDN is serving a cached error, and purging that URL fixes it. If it stays, the problem is at the origin.

How is a 503 different from a 500, 502, 504 or 429?

The other codes describe a fault, a broken handoff or a single client over its limit. A 503 describes a service that is unavailable for now. That changes what you do next.

Hosts don’t always pick the textbook code. Some stacks turn a PHP crash into a 503 instead of a 502, so use the table to decide where to look first, not as proof of the cause. If the PHP error log shows a fatal error at the same timestamp, follow the log. Our WordPress fatal error guide shows how to read the file path it names. WordPress.org’s Recovery Mode documentation notes that Recovery Mode doesn’t activate for fatal errors in cron or background tasks, so a missing recovery email doesn’t mean nothing failed.

When is it safe to retry a 503?

When the request only reads something. Reloading a page or fetching an image is a GET request, and repeating it changes nothing. Under heavy load, though, every reload occupies a worker again, so wait for the Retry-After period if there is one. Refreshing again and again makes an overloaded server slower to recover.

Checkouts, form submissions and cart updates are different. The server may have recorded the order or taken the payment before a proxy or a timeout sent the 503 back. Before anyone resubmits, check the WooCommerce orders list, the payment provider’s dashboard or the form plugin’s entries. A 503 on a POST tells you the response failed. It doesn’t tell you the action failed.

For scripts and integrations that call your site, use bounded exponential backoff with jitter. That means waiting longer after each failure, adding a random offset so clients don’t retry in sync, capping the delay, and stopping after a fixed number of tries. Tight retry loops from monitors and integrations are a common way a brief overload turns into a long one.

When should your site return a 503 on purpose?

When you take it offline for a short, planned reason: a migration, a database restore, a pause in sales. Google’s guidance on temporarily pausing or disabling a website recommends a 503 page for brief shutdowns lasting a few days at most. The page should be lightweight, include a Retry-After header and tell visitors when you’ll be back or how to reach you. Google’s crawl-rate documentation puts the window at a couple of hours to one or two days. If the closure will run longer, serve a normal 200 placeholder page instead. A 503 that lasts weeks tells Google the site is unreliable.

The same page warns against two shortcuts: blocking the site in robots.txt, and adding noindex to shut it down. Both are harder to undo than a status code.

A few habits keep planned downtime honest:

• Check the status, not the look. Run curl while logged out and confirm you get 503 and not 200. A maintenance page that returns 200 tells search engines the holding page is your content.
• Prefer a server-level 503 for real work. A rule in .htaccess, Nginx or the CDN keeps working even when PHP or the database is the thing you’re working on. A plugin-based 503 needs WordPress to load before it can respond.
• Clear every cache when you finish. The WordPress cache, the host’s server cache and the CDN each store their own copy. Visitors can keep seeing the holding page after you switch it off, or see the live site while the plugin still thinks it’s on.

Our article on coming soon text in WordPress covers the visible side: what the holding page should say.

What should you do with an unplanned 503?

Write down the URL, the time with time zone, the status, the headers and which actions fail. Then match that against the table above before you touch a plugin. Disabling every plugin on a live store removes checkout, forms and security together. It often hides the evidence too, and it rarely helps when the real problem is a full worker pool. If the host’s graphs show a limit being hit at that timestamp, send them that evidence. If the PHP log names a file, start there. The step-by-step 503 fix covers plugin isolation over FTP, Health Check troubleshooting mode and the CDN purge.

If you’d rather not dig through logs yourself, SiteSelf can find and fix the failing layer on request through chat. It needs hosting (SSH) access for log and file work, and it reports what it changed and what it checked.

When the site is back, check the things a working homepage can hide. Load checkout and wp-admin while logged out and logged in. Reconcile any orders placed while the site was failing. Confirm that scheduled posts actually went out, because WP-Cron only runs when visitors load pages, and nobody got through during the outage.

Frequently asked questions

You rename a service page, tidy up a product category, or move the site to HTTPS. The new URL works. But Google still has the old one indexed, other sites still link to it, and customers still have it bookmarked. A 301 redirect connects those old requests to the new address. Whether your search traffic makes it across depends almost entirely on how carefully you set up those redirects.

This article explains what a 301 does for search, when it’s the right response, and where WordPress sites usually get it wrong. For step-by-step setup, see our guide to redirecting a page in WordPress.

What a 301 tells Google, and what it doesn’t promise

A 301 is a server response that says “this resource has moved permanently.” The new address goes in the Location header. Browsers and crawlers follow it automatically. Google’s redirect documentation treats a permanent redirect as a strong signal that the destination should become the canonical URL, the one shown in search results.

The old fear was that every 301 “leaked” a fixed share of link value. Google has since said the opposite. Its site moves and migrations guide says permanent redirects don’t cause a loss in PageRank. The same guide also warns that rankings can fluctuate while Google recrawls and reprocesses the moved URLs. Both statements are true. A 301 carries the signals over. It doesn’t guarantee the new page ranks where the old one did.

That gap matters most when the content changes too. If the new page drops the text, headings or offer that ranked the old one, the redirect carries signals to a weaker page. Change the URL and the content at the same time and you won’t be able to tell which change caused the drop.

Big moves can take a long time to settle. In a 2025 Search Engine Journal study of 892 domain migrations, estimated organic traffic took an average of 523 days to match the old domain. The sample was self-selected and limited to domain moves, and the study doesn’t separate the effect of redirects from everything else that changed. A single slug change on a small site is a much smaller event. Still, plan for some movement.

When is a 301 the right response?

Use a 301 when the move is permanent and the new page is a real replacement for the old one. Google’s test is simple: if you expect to reverse the redirect later, it isn’t permanent, so use a 302 or 307 instead. A 308 is also permanent. The difference from a 301 is that it keeps the request method.

WooCommerce’s Product 404 Redirects documentation draws the same line for stores. It recommends a 301 for permanently deleted products and a 302 for products that are only temporarily unavailable. It also warns against choosing a destination that redirects back to the original URL.

The row people resist most is the last real one: deleted, nothing equivalent. Sending every dead URL to the homepage feels safer than a 404. Google’s migration guide says otherwise. Redirecting unrelated old URLs to the homepage can confuse visitors, and Google may treat those redirects as soft 404s. If a page has no real replacement, a clear 404 is the honest answer, and you can make it a useful one with a custom 404 page.

Why WordPress changes URLs without redirecting them

Most redirect problems on WordPress start with a URL that changed and nobody added a redirect for it. WordPress makes these changes easy and covers them only partly.

Changing permalinks redirects nothing. When you click Save under Settings > Permalinks, WordPress applies the new structure and flushes its rewrite rules. Old URLs aren’t mapped to new ones. Switch from /2024/05/post-name/ to /post-name/ and every dated URL that Google has indexed can start returning 404s. WooCommerce’s permalinks documentation gives the same warning for product and category bases.

Old-slug redirects cover only some cases. WordPress core has wp_old_slug_redirect(), which looks up a post’s past slugs when a request would otherwise 404. It’s useful. But it doesn’t cover structure changes, and you shouldn’t assume it caught a particular URL. Test the old address itself. Our explainer on what a WordPress slug is covers where the slug ends and the rest of the permalink begins.

Canonical redirects aren’t bugs. redirect_canonical() sends requests to the URL WordPress considers correct, based on host, HTTPS and trailing slash. Owners sometimes see an unexpected 301 from it and switch it off. That can leave duplicate versions of the same page reachable, which is the problem it exists to solve.

Custom code defaults to temporary. In WordPress developer resources, wp_redirect() takes a status of 302 by default and doesn’t stop execution. For a permanent move in a theme or must-use plugin:

wp_safe_redirect( home_url( '/new-page/' ), 301 );
exit;

Leave off the 301 and you’ve told Google the old URL is coming back.

Where should the redirect live?

A WordPress request can be redirected by WordPress core, a redirect plugin, an SEO plugin’s redirect manager, .htaccess or Nginx rules, your host’s dashboard, and Cloudflare. Any of these layers works. The trouble starts when two of them handle the same URL. Pick one owner for each rule and write down which one it is.

Google prefers server-side redirects when you can use them. A plugin like Redirection still returns a real 301 from PHP, so it’s a sound choice for owners without server access. Server rules handle the request before WordPress loads, which suits large rule sets. A mistake in a server rule, though, can break more than the page you meant to move. Our guide to htaccess 301 redirects shows where custom rules go so WordPress doesn’t overwrite them.

Two host differences catch people after a migration:

• WP Engine has deprecated .htaccess support. Redirects belong in Web Rules, which run in order. A broad rule placed above a specific one wins. Old .htaccess redirects may simply stop working after a move.
• Kinsta’s redirect tool treats every source as a regular expression. Anchor paths with ^, and with $ for exact matches, or a rule can match its own destination and loop. Kinsta also says the tool can’t redirect query strings, and asks you to contact support for those.

If you’d rather hand off the map and the checks, SiteSelf handles 301 redirects and SEO settings through chat. It uses its connector plugin for plugin-level redirects and hosting access for server rules, and it reports what each old URL returns afterwards.

The mistakes that actually cost traffic

When practitioners on r/Wordpress, r/webdev and the wordpress.org forums describe a traffic collapse after a rebuild, the cause is rarely the 301 status code. It’s usually one of four things, roughly in this order of how often they come up.

Old URLs that nobody listed

A rebuild changes the URL structure, someone redirects the pages in the main menu, and hundreds of old posts, product URLs and PDFs end up returning 404s. Fix this before launch. Export every URL from your sitemap, Search Console’s indexing and performance reports, analytics landing pages and your backlink tool. Then map each one to its closest real equivalent. A poster on r/webdev who migrated 3,100 URLs from a 14-year-old WordPress site said starting that spreadsheet late was the biggest regret of the project.

Bulk redirects to the homepage or a broad category

For large catalogues, the approach practitioners defend most often is a hybrid. Map your high-value URLs one to one. Send low-value ones to the closest category or brand page that genuinely fits. Return a 404 or 410 where nothing fits. Plugins that redirect every 404 to the homepage are popular, but the Redirection plugin’s own FAQ advises against redirecting all 404s.

Chains

A chain happens when site moves pile up: http:// goes to https://, then to www, then to the new slug. Google’s redirect documentation says Googlebot follows up to 10 hops but advises avoiding chains, ideally keeping them to 3 or fewer and always under 5. Point every old URL directly at the final page. Then update your menus, internal links, canonical tags and sitemap so your own site never goes through a redirect at all. Our guide to updating internal links in WordPress covers the editor side.

Loops

ERR_TOO_MANY_REDIRECTS means two layers disagree. A common case is documented by Cloudflare: in Flexible SSL mode, Cloudflare talks to your server over HTTP. If the server also redirects HTTP to HTTPS, the request bounces between them forever. Cloudflare’s fix is Full mode or higher, which needs a certificate on the origin server. Other causes are a force-HTTPS plugin turned on before HTTPS actually works, www and non-www settings that disagree, and regex rules with no anchors. SSL errors behind Cloudflare often show up alongside loops. Trace the chain before you clear caches or disable plugins. Those steps can hide the problem without telling you which rule caused it.

How to tell a 301 is doing its job

Check the actual HTTP response, logged out, after clearing your page cache. A browser alone won’t tell you much. Browsers cache 301s, so your browser may keep following a rule you’ve already changed. From a terminal:

curl -sIL https://example.com/old-page/

Each HTTP/ line is one hop. A good result shows one 301, a Location header with the final URL, and then a 200. Two or more 3xx lines mean a chain. A 302 where you expected a 301 means the wrong status. Repeating URLs mean a loop. The Redirection plugin also has an HTTP checker that shows each hop, if you’d rather stay in wp-admin.

Then check the destination like a visitor would. Does the page load, answer the same question, and still let people buy or get in touch? In Search Console, “Page with redirect” is the expected status for a URL that redirects on purpose. A “Not found (404)” report that suddenly fills with old URLs means pages were missed.

Keep the redirects. Google’s migration guide says to keep them for at least a year and to consider keeping them indefinitely, because people will keep clicking old links long after Google has updated its index. If you moved domains, keep the old domain registered so its redirects keep working.

Frequently asked questions

A fresh WordPress install gives posts addresses like example.com/?p=123. WordPress’s own documentation calls this Plain structure reliable on any server but not user-friendly or optimized for search. Fixing it takes one setting and about ten seconds, as long as you do it before the site has a few hundred indexed pages.

That timing is the whole story. Choosing a good URL structure is a one-time decision with almost no risk. Changing an existing structure is a migration: every old address needs to send people and search engines to its new one. URLs are one item on a longer list. The rest is in our guide to doing SEO on WordPress.

What makes a URL SEO friendly, and what doesn’t

An SEO friendly URL tells a person and a crawler what the page is about before they open it. /services/web-design/ does that. /page?id=8472 doesn’t. Google’s URL structure guidance asks for descriptive words instead of long IDs, hyphens between words, as few unnecessary parameters as possible, and consistent casing. Google treats /APPLE and /apple as two different URLs.

Google does not set a character limit. It does not say that shorter URLs, extra keywords or a missing /category/ segment rank better. Rank Math, which sells a feature for removing the category base, says in its own documentation that doing so is not guaranteed to improve rankings. Clean URLs are hygiene. They help people read and trust a link, and they keep your site consistent. They will not lift a weak page.

What does hurt is instability. Practitioner threads on Reddit and X rarely report a URL cleanup that boosted traffic. They often report a relaunch where addresses quietly changed and pages started returning 404s.

Which permalink structure should a new site use?

Post name, for nearly every site. It produces example.com/your-post-title/ and stays accurate however your categories change later. To set it:

1. In the dashboard, go to Settings > Permalinks.
2. Under Permalink structure, select Post name. The custom field shows /%postname%/.
3. Click Save Changes.
4. Open any post on the front end and check that the address now ends in its slug, not ?p=.

If you write a custom structure, use structure tags such as %postname% and leave the domain out of the field. WordPress adds it. The same screen holds the Category base and Tag base fields. Leave them empty unless you have a reason to change them.

When category or date in the URL makes sense

Category plus post name (/%category%/%postname%/) works when your categories are few, short and unlikely to change. The cost: moving a post to another category changes its URL, and that needs a redirect. Dates suit news sites, where readers care when a story was published. On evergreen guides, a date keeps showing the original year long after you’ve updated the article.

How to write slugs that hold up

The slug is the last part of the URL, and it is separate from the title. WordPress builds it from the title when you first save. You can edit it in the post’s settings panel before you publish. Our explainer on what a WordPress slug is covers where to find it. Rules that work in practice:

• Describe the page in a few words: /small-business-accounting/, not /accounting-services-for-every-small-business-owner-2026/.
• Use lowercase and hyphens. Google recommends hyphens over underscores.
• Include the main term once if it describes the page naturally. Don’t repeat it.
• Don’t strip every stop word by reflex. /how-to-fix-a-leaking-tap/ reads better than /fix-leaking-tap/, and WPBeginner notes that keeping stop words can help readability.
• Get the slug right before you share the post. Rewriting a title later doesn’t change the URL, and it shouldn’t.

The common “under 60 characters” or “three to five words” rules are editorial habits, not Google requirements. A slug that could be shorter but is accurate is fine. Leave it alone.

Why changing URLs on a live site is a migration

Each changed URL is a new address. That applies whether you switch the permalink structure, rename a WooCommerce base, drop trailing slashes in a redesign, or lowercase addresses during a move. Unless each old URL redirects to its new one, links, bookmarks and search results all lead to 404s. WP Engine’s support docs warn that changing an established site’s structure can cause widespread 404s and affect SEO. WordPress.com notes that posts may not redirect automatically when the structure changes.

A common mistake: people assume Save Changes on the Permalinks screen handles this. It doesn’t. Saving rebuilds WordPress’s rewrite rules, which fixes stale routing. It creates no redirects for addresses that have actually moved.

Before changing an established structure, ask whether you have a concrete reason. One example from Reddit: a long-running news site wanted category data in its URLs for analytics. Commenters suggested tracking the category in GA4 instead of moving thousands of articles. If the change is still worth it, Google’s site move documentation describes the method:

1. Export every current URL from a crawl, your sitemap or Search Console.
2. Map each old URL to its closest new equivalent. Don’t send unrelated pages to the homepage. Google may treat those as soft 404s.
3. Add server-side 301 or 308 redirects that go straight to the final URL, with no chains.
4. Test the map on staging, then on the live site with a sample of old URLs.
5. Update internal links, the XML sitemap and canonical tags to the new addresses.
6. Keep the redirects for at least a year, and watch 404 reports and Search Console after launch.

Even a clean migration can cause rankings to move for a while as Google recrawls. Use one redirect layer, either a plugin, server rules or your host’s tool, not several. Overlapping layers are how sites end up with ERR_TOO_MANY_REDIRECTS. For single pages, see how to redirect a WordPress page. For server rules, see htaccess 301 redirects in WordPress. If you would rather hand off the redirect map and the checking, SiteSelf handles 301 redirects and SEO settings through chat. Plugin-level redirects need the connector plugin, and rules in .htaccess need hosting access.

On redirect plugins: Yoast’s redirect manager, including automatic redirects when a slug changes, is part of Yoast SEO Premium, not the free plugin. It uses PHP redirects by default. Whichever tool creates the redirects, open a few old URLs yourself and confirm where they land.

WooCommerce: product and category bases

WooCommerce adds its own fields under Settings > Permalinks. Product URLs can use /product/name, /shop/name, /shop/category/name or a custom base, and category and tag bases are set separately. WooCommerce’s permalink documentation makes three points worth knowing before you touch them:

• Don’t use the same base, such as shop, for products and product categories. WordPress may no longer be able to tell them apart.
• If you change product URLs, old product links return 404 unless you redirect them.
• Attribute archive URLs only work if Enable archives is turned on for that attribute.

Putting the category in product URLs looks tidy until a product sits in two categories. Then it can have two addresses, and you have to manage canonicals for both. On an existing store, the safest choice is usually to keep the defaults.

Should you strip the category base?

Only if you understand the trade. Rank Math’s Strip Category Base setting (Rank Math SEO > General Settings > Links, visible in Advanced mode) removes /category/ and redirects existing category URLs. Rank Math warns that a category slug matching a post, page or product slug can cause unexpected results. WooCommerce support has advised against removing the product category base for the same reason. A middle path Reddit store owners suggest is a short, unique base like /c/, which keeps the URL short without the collision risk.

Why pretty permalinks return 404s, and how to fix them

The classic symptom is that the homepage loads but every post and page returns 404. Work through these causes, most frequent first:

1. Stale rewrite rules. These are common after a migration, an update or a new custom post type. Go to Settings > Permalinks and click Save Changes without changing anything. If that fails, switch to another structure, save, switch back and save again.
2. An .htaccess file WordPress can’t write to. On Apache, the Permalinks screen then shows “You should update your .htaccess file now.” along with the rules to add. Back up the file first, then paste the rules into the # BEGIN WordPress block, keeping your own custom rules above it.
3. A server that doesn’t route requests to WordPress. Apache needs mod_rewrite and permission for .htaccess overrides. Nginx ignores .htaccess completely and needs its server block configured. Resaving can’t fix either problem. Your host has to.
4. A plugin conflict. A WordPress.org support thread documents TranslatePress 2.8.3 breaking WooCommerce product category pagination on several client sites. If resaving helps only until the next page load or update, a plugin is probably rewriting the rules. Deactivate plugins one at a time on staging until the 404s stop.
5. A slug collision. A page and a category, or a page and a plugin route, share the same path. WordPress’s Common Errors handbook lists renaming the conflicting slug as the remedy. Rename it, then resave permalinks.

Stop and get help when inner pages still return 404 after a resave and a clean .htaccess, when you’re on Nginx and don’t have access to the server config, or when the 404s started right after a URL change and you have no list of the old addresses. The first two are hosting problems. The third needs someone to rebuild the redirect map from crawl data and Search Console before more traffic leaks away.

What to do about duplicate URLs from filters and parameters

Store filters, sort orders, tracking tags and variant parameters can give one page dozens of addresses. Google’s guidance on consolidating duplicate URLs treats redirects and rel="canonical" as strong signals and sitemap inclusion as a weaker one. A canonical is a signal Google weighs, not an order it must follow. In practice: redirect when an old URL is gone for good, use a canonical when both versions have to stay live, and link to the same preferred URL everywhere, in menus, internal links and the sitemap. For product variants passed as optional parameters, point the canonical at the clean product URL.

Frequently asked questions

Your page is called “Emergency Plumbing Services” and its address ends in /emergency-plumbing-services/. That last segment is the slug. It looks like a small text field. It is also the public address that bookmarks, emails, ads and search results point to.

The definition takes one sentence. The trouble starts around it: a stray -2, a page that returns 404 after a rename, or a “quick” permalink change that breaks every link on the site. This article covers what a slug is, how WordPress makes one, and how to change one without losing traffic.

What is a slug in WordPress, exactly?

A slug is the readable, URL-friendly name of one item on your site. It is usually the last part of the URL. In example.com/about-us/, the slug is about-us. Posts, pages, WooCommerce products, categories, tags, custom post types and authors all have one.

Child pages build on their parent’s slug. In example.com/services/consulting/, consulting is the child page’s slug and services is the parent’s. If you change the parent’s slug, the child’s URL changes too.

The word means other things in WordPress as well. A plugin slug is the folder name a plugin uses in the directory. An author slug is the public name in an author archive URL. This article is about content slugs, the ones you see in the editor. If you are still setting up your site’s structure, our guide to adding pages in WordPress explains why the slug is worth deciding before launch.

How is a slug different from a permalink?

The slug names one item. The permalink is that item’s full address. The permalink structure is the site-wide pattern that decides where the slug sits in the address. WordPress’s permalink documentation describes permalinks as the permanent URLs of your posts and pages, and you set the structure under Settings > Permalinks.

Keep the difference in mind, because the two changes carry very different risks. Editing one slug changes one URL. Changing the structure changes every post URL on the site at once.

How does WordPress create a slug?

WordPress builds the slug from the title when you first save. It lowercases the text, turns spaces into hyphens and strips punctuation and characters that are not allowed in a URL. The core function that does this, sanitize_title(), also converts accented letters to plain ASCII where it can. “Café Menu” becomes cafe-menu.

Non-Latin titles are where the automatic slug lets people down. Developers often complain that slug tools handle umlauts, apostrophes and Cyrillic badly. If you publish in Chinese, Russian or Hebrew, look at the generated slug before you publish and decide whether you want a transliteration, a translation or the original script.

One behaviour surprises a lot of people. Once an item is published, changing its title does not change its slug. WooCommerce’s product editor documentation says the same for existing products. That works in your favour: you can retitle a page as often as you like, and its URL stays put until you edit the slug yourself.

Where do you find and edit a slug?

Where the field sits depends on the editor and the content type. The job is always the same: open the item, find the URL or slug field, change it, save, then load the new URL.

• Block editor (posts and pages): open the Settings sidebar with the panel icon at the top right, pick the Post or Page tab, and click the URL or slug field. WordPress.org’s Settings sidebar documentation covers this panel. The label has moved between versions, so look for the URL in that tab.
• Classic editor: the permalink appears under the title once a draft is saved. Click Edit next to it.
• Categories and tags: go to Posts > Categories or Posts > Tags and use Quick Edit next to the term. A category slug change moves the archive URL and every link to it.
• WooCommerce products: use the Edit link next to the product URL, or the slug panel. Product and category bases, such as /product/, are set separately under Settings > Permalinks > Product permalinks.

Save a draft before you publish, so you can check the slug before any visitor or crawler sees the URL.

Why did WordPress add -2 to my slug?

Something else already uses that slug. WordPress won’t give two items the same address, so it appends a number. The suffix is a symptom, not an error, and the item causing it is usually one you have forgotten about.

Check these places in order:

1. Trash. A trashed page still holds its slug. A WordPress.org forum moderator points to trashed posts and leftover imports as the usual culprits.
2. Media. Uploading pricing.jpg can give the attachment the slug pricing, and then your Pricing page becomes pricing-2.
3. Drafts and other content types. An old draft, a product or a custom post type item can hold the slug.
4. Numbers only. A slug made only of digits, like 2026, can get a suffix too, because WordPress may read it as an ID or a date.

Once you have found the item, delete it permanently or change its slug. Then go back to your page and type the slug you want into the field. WordPress will not rename the -2 page for you when the original goes. Clear your cache and load the URL.

That same moderator also warns against deleting database rows to clear a hidden conflict. Use the admin screens first. Some cases stay stuck. One WooCommerce store owner on Reddit reported -8 suffixes on variable products coming back after hours of cleanup, and nobody posted a confirmed fix. If you reach that point, it is a job for a developer.

What happens when you change a published slug?

The old URL can stop working. Every link pointing at it, from your menu, other sites, old emails or Google’s index, can then land on a 404. A published slug change is a URL migration, however small the edit looks.

WordPress gives you some cover, but not everywhere. It remembers old post slugs and often redirects them. WPBeginner’s redirect guide says this covers posts but not pages. Plugins and server rules can also get in the way. Don’t trust it. Test the old URL every time.

To change a live slug safely:

1. Copy the full old URL, including any parent path or language prefix.
2. Change the slug and save.
3. Add a permanent 301 redirect from the exact old URL to the new one. Our guide to redirecting a WordPress page walks through the options.
4. Load the old URL in a private window. It should go straight to the new page in one hop, with no chain.
5. Update your menus and the internal links that use the old address.

Don’t point old URLs at the homepage. Google’s site move guidance says redirects to irrelevant pages may be treated as soft 404s. If nothing replaces the old page, a useful 404 page is the honest answer.

Changing the whole permalink structure is a much bigger job. In a Rank Math support thread, a user switched structures and found old links sent to the homepage. Support explained that the plugin’s auto-redirect covers changes to individual slugs, not structure changes, and pointed to the Permalink Migration option in the Redirection plugin. On an established site, plan per-URL redirects before you touch that setting.

If you would rather not do this by hand, SiteSelf can make the slug change, add the 301 and fetch the old URL to confirm it lands on the new page, all from a chat request. That is part of its WordPress SEO and redirect work.

Do slugs help SEO?

A little, mostly through clarity. Google’s URL structure guidelines ask for simple, readable URLs, hyphens rather than underscores, and words in your audience’s language. A slug like /wedding-photography/ tells a searcher what is behind the link before they click.

No source we found measures a ranking gain from the words in a slug. Yoast suggests three to five words, roughly 30 to 50 characters. That is editorial advice, not a measured threshold. Use the main term if it fits naturally, keep the slug close to the page’s title, and stop there.

The bigger SEO risk is breaking URLs, not choosing imperfect ones. Rewording a working slug to squeeze in a keyword trades a known-good URL for a redirect and a recrawl. Our guide on how to do SEO on WordPress puts slugs alongside the titles, links and content work that make more difference.

Why does a page return 404 after a slug or permalink change?

If one old URL is broken, it is missing a redirect. If many pretty URLs break at once, the cause is usually routing. WordPress’s common errors handbook gives the order to work in:

1. Stale rewrite rules. Open Settings > Permalinks and click Save Changes without changing anything. That rebuilds the rules.
2. Server rewrite support. On Apache, pretty permalinks need mod_rewrite and a correct .htaccess file. If saving does nothing, ask your host to check both.
3. Name collisions. A custom post type with the same name as a page causes 404s. Rename the page and its slug, save the structure as Plain, then switch back to your preferred structure and save again.
4. Plugin rewrite rules. In one WordPress.org report, a links plugin broke every two-segment URL on a site. Saving permalinks did not help, and deactivating the plugin did.

Saving permalinks again and again will not fix a real collision. Once the save has failed and the host has checked the server, deactivate plugins one at a time on a staging copy. If the cause still won’t show, get a developer.

Frequently asked questions

The WordPress.org listing for the Starter Templates plugin offers more than 300 ready-made website designs you can import. Every business template makes the same pitch: pick a design you like, and the site is mostly done.

Mostly done is where the trouble starts. “Template” covers at least four different things. The demo is built from someone else’s content. And the template price is the smallest number in the project. This article covers what you are actually getting, how to choose a template for the site you will run (not the one in the demo), and how to install it without overwriting a site you already have. If you are still deciding whether WordPress suits your business at all, start with whether WordPress fits a business website.

What “template” actually means in WordPress

The word can mean four different things, and each one installs in a different place. Most first-day problems come from mixing them up.

• A theme. This controls the design of the whole site. You install it at Appearance > Themes > Add New Theme > Upload Theme. Every theme has a style.css file at its top level.
• A starter template or starter site. This is a complete pre-designed site, imported by a plugin on top of a theme. It brings pages and layouts, and often the global design settings too. Brainstorm Force’s Starter Templates plugin is one example. Its WordPress.org listing describes 300+ website templates, page templates and block patterns for Elementor and the block editor.
• A builder kit. This is a set of layouts for one page builder, usually Elementor. It is not a theme. You import it through the builder or through the marketplace’s own plugin.
• Page templates and block patterns. These are layouts for a single page or section inside the theme you already have.

Upload the wrong one and you get the most common first-day error. If you push a marketplace download bundle, a builder kit or a plugin through the theme installer, WordPress replies: “The package could not be installed. The theme is missing the style.css stylesheet.” The fix is to unzip the download and find the installable theme ZIP inside. It is usually the file named after the theme. Upload that file. Kits and starter sites go through their own importers.

When a template is the right choice for a business site

A template is the right call when the site is standard: a handful of service pages, an about page, a contact form, maybe a blog or a small shop. Automattic’s guidance for agencies (May 2025) puts the line in a sensible place. Ready-made themes suit simpler sites, tight budgets and short deadlines. Custom builds earn their cost when you need unusual features, specific branding or integrations.

Practitioners on r/Wordpress give consulting and local service businesses the same advice. Start from a business starter template, replace every piece of content, and change the colours and fonts. Don’t redesign the structure.

A template stops paying off when you have to fight it on every page. If your booking flow, quote form or product logic is something neither the template nor a common plugin does, you will pay for custom work anyway. On top of that, you will pay to work around a layout you never needed.

Why your site won’t look like the demo

The demo is a finished site with someone else’s content in it: professional photos, copy written to fit each box, menus already built. Install the bare theme and you get the design with nothing in it. Import the starter site and you get the sample content, which you then replace piece by piece. Copy that is longer or shorter than the placeholder text changes the layout.

The second cause is a missing dependency. Many starter designs need a specific page builder. On the Starter Templates support forum, one user found that their favourite template had become Elementor-only. It would not import as a block-editor design. That is common: W3Techs detects Elementor on 31.5% of WordPress sites as of October 2026, so plenty of templates assume you have it. Some builder kits also need the paid version of the builder for certain layouts.

The third cause is caching. If your changes don’t show, clear the caching plugin, the host’s cache and your browser cache before you decide the import failed.

How to choose a template for the site you’ll actually run

Start from the work the site has to do, not from the screenshot. Go through these checks in order. Each one rules out more than the one before.

1. List the pages and features you need now. Services, contact, bookings, a shop, a portfolio. Cross off any template that only works with a plugin you don’t want.
2. Decide who will edit the site. A marketer who builds a landing page every week may be happy in a visual builder. An owner who changes opening hours twice a year wants the block editor and as few settings panels as possible. In one r/webdev thread, a developer complained that in all-in-one themes, small changes mean hours of hunting through settings.
3. Read the dependency list. Which builder does it need? Is the builder free or paid? Which plugins come bundled? A paid builder licence is a recurring cost the template price doesn’t show. The builder also decides how hard it will be to leave.
4. Check that someone maintains it. Look at the last-updated date, the changelog and whether the support forum gets answers. One agency on r/Wordpress stopped using one-off marketplace themes because some of them disappeared.
5. Test it with your content. On a staging copy, add your real homepage text, your logo and a typical photo from your phone, then check it on a phone. Speed tests of a bare theme tell you little about a site with forms, analytics and images loaded.
6. Ask what leaving would cost. When you switch themes, your posts and pages stay. Layouts built with the old theme’s own builder or shortcodes don’t come with you.

Price is not a quality signal. A free theme is often enough for a brochure site. Pay when you need a specific feature or real support, and check that the feature is in the tier you are buying, not the one above it.

How to install a template without breaking an existing site

Import onto a fresh install or a staging copy, never straight onto a live site that already has content. This is the step most people skip, and skipping it is how a quick refresh turns into a rebuild.

Here is a real case. A user on the WordPress.org forums imported a restaurant starter template into an existing Elementor site. Colours, fonts, layouts and responsive breakpoints changed across pages they had already built. Support explained that the import does not delete content, but the Customizer settings it brings apply to the whole site. The way back is a Customizer backup if you have one, or redoing the settings by hand. Support’s advice for next time was to import on a new install.

1. Back up files and the database. WooCommerce’s backup documentation says a store keeps its data in two places: the wp-content folder (themes, extensions, media) and the database (products, orders, posts, pages). Back up both, and know where backup plugins fall short before you rely on one.
2. Make a staging copy through your host, or a fresh install on a subdomain.
3. Install the theme, plus the builder and plugins the template lists. Nothing else yet. Fewer active plugins means fewer things to go wrong during the import.
4. Run the import. If it fails, don’t rerun it straight away. Check the theme’s documented PHP requirements, usually memory limit, max execution time and upload size, and ask your host to match them. Also look at any proxy in front of the site. In a ColorMag support thread, the server limits were double the recommended values and the import still failed. Cloudflare was cutting off the request, and bypassing it during the import fixed the problem.
5. Replace the content and set up the menus. If pages return 404s, re-save Settings > Permalinks.
6. If you see “There has been a critical error on this website”, that is usually a theme and plugin conflict. Deactivate the plugins, switch to a default theme, then turn things back on one at a time. The guide to a WordPress white screen covers the details.
7. Move the finished copy to live once it works, not before.

Any code changes after that belong in a child theme, so that a parent theme update doesn’t wipe them. The guide to customizing a WordPress template safely covers which layer to edit.

What a template costs compared with the whole site

The template is cheap. Folio3’s 2026 cost guide puts a premium theme at $40 to $200, paid once. Add any builder licence or add-ons, which are often billed yearly.

The site is not cheap. Freshy’s 2026 rate guide prices a 5 to 15 page small-business site at $2,000 to $5,000 from a freelancer and $5,000 to $10,000 from an agency. Folio3 estimates 30 to 50 hours for a freelancer-built brochure site, about $3,000 to $5,000. The gap between those numbers is content, images, setup and testing. A template shortens the design work. It does not write your service pages or take your photos.

Freelancers should price with that in mind. A template site sold at template prices leaves out the discovery and content work, and that is the part that takes the time.

What to check after launch

Check that the structure underneath is as good as the surface. A polished template can hide headings that are really bold paragraphs, or headings picked for their size rather than their order. W3C’s accessibility tips for developers include keyboard access and setting the page language. Both are worth rechecking after any template change.

A quick pass takes ten minutes. Tab through each main page without a mouse. Confirm that each page has one main heading and that the rest follow in order. Check the site language under Settings > General. Then delete the demo pages, the sample posts and any theme you aren’t using.

After that, the work is ordinary edits and updates. Read up on how theme updates work and fail, especially for themes bought outside WordPress.org. If you would rather describe those edits than make them yourself, SiteSelf handles small-business site updates through chat on the site you already have, though it refuses pages owned by Elementor, Divi or Beaver Builder, which is one more reason to know what your template runs on.

Frequently asked questions