Blog

  • How to switch off automatic updates in WordPress

    Key takeaways

    • To stop one plugin or theme, use its Disable auto-updates link under Plugins or Appearance → Themes. You need WordPress 5.5 or later.
    • WP_AUTO_UPDATE_CORE only affects core. AUTOMATIC_UPDATER_DISABLED turns off the whole background updater, and WordPress’s handbook discourages it.
    • If updates keep happening after you turned them off, look for a host updater or a file in wp-content/mu-plugins before you change anything else.
    • Returning false from auto_update_plugin also blocks the security updates WordPress.org pushes for actively exploited flaws.
    • Updates that never run usually come from a cron, loopback, permissions or disk space problem. Changing a setting won’t fix any of those. Tools → Site Health is where to look first.

    A plugin updates overnight. In the morning the checkout buttons are in the wrong place, or the site shows a critical error. The obvious response is to switch off automatic updates and approve everything by hand from now on.

    That works if you pick the right control, and if someone really does apply security fixes afterwards. WordPress has at least four separate update controls. Your host may run a fifth that ignores all of them. Most “I turned it off and it still updated” threads come from changing a setting that doesn’t govern the update the person wanted to stop. If an update has already failed or left the site half-updated, fix that first with our guide to failed WordPress updates. Then come back here and decide on a policy.

    Which switch stops which update

    Each control covers one kind of update. Pick the one that matches what you want to stop.

    What you want to stopControlWhere
    One plugin or one theme“Disable auto-updates” linkPlugins → Installed Plugins, or Appearance → Themes
    Major core releases onlydefine( 'WP_AUTO_UPDATE_CORE', 'minor' );wp-config.php
    All core updatesdefine( 'WP_AUTO_UPDATE_CORE', false );wp-config.php
    All plugins or all themesauto_update_plugin / auto_update_theme filtersA must-use plugin
    The whole background updaterdefine( 'AUTOMATIC_UPDATER_DISABLED', true );wp-config.php

    Start at the top of the table. The further down you go, the more you switch off, and the more likely you are to block a security fix you would have wanted.

    How to stop one plugin or theme from updating itself

    If one plugin broke something, turn off auto-updates for that plugin and leave the rest alone. WordPress.org’s documentation says these per-item controls need WordPress 5.5 or later. If you aren’t sure which version you run, check your WordPress version first.

    1. Go to Plugins → Installed Plugins.
    2. In the Automatic Updates column, click Disable auto-updates next to the plugin.
    3. For a theme, go to Appearance → Themes, open the theme’s details and click Disable auto-updates. If you use a child theme, the parent theme is the one that receives updates.

    To bulk-change plugins, tick several and pick Disable Auto-updates from the Bulk actions menu. On the command line, WP-CLI does the same with wp plugin auto-updates disable plugin-slug (available since WP-CLI 2.5.0) and wp theme auto-updates disable theme-slug.

    The link column should now say “Enable auto-updates” for that item. One limit to keep in mind: this toggle doesn’t stop your host’s updater, and it doesn’t stop a security update WordPress.org decides to push.

    How to stop major core releases but keep security fixes

    Core has its own constant. Open wp-config.php and add one of these lines above the line that reads /* That's all, stop editing! */:

    // Keep minor and security releases, skip major versions
    define( 'WP_AUTO_UPDATE_CORE', 'minor' );
    
    // Or: turn off all automatic core updates
    define( 'WP_AUTO_UPDATE_CORE', false );

    WordPress’s Developer Handbook says this constant overrides the core auto-update setting on the Updates screen. It has no effect on plugins or themes. People mix this up often enough that a WordPress.org moderator had to explain in a 2025 support thread that WP_AUTO_UPDATE_CORE covers core only, while AUTOMATIC_UPDATER_DISABLED covers everything.

    The 'minor' value is the setting most sites should use. Minor releases carry the security and maintenance fixes, and they are the ones you least want waiting on someone’s calendar.

    Edit this file carefully. A missing semicolon or a stray quote takes the whole site down. Keep a copy of the original file so you can put it back in seconds. Editing wp-config.php needs file access through your host’s file manager, SFTP or SSH.

    How to switch off all automatic updates, and what that costs

    One line turns off the whole background updater:

    define( 'AUTOMATIC_UPDATER_DISABLED', true );

    WordPress’s handbook calls this “generally discouraged”, because minor and security updates are what keep a site secure. Treat it as a policy decision, not a fix. The site stays exactly as it is until someone logs in and updates it. If nobody owns that job, the site falls further behind every week.

    To turn off plugin or theme auto-updates across the site but leave core alone, use filters. The handbook says filters belong in a must-use plugin, not in wp-config.php, where they can conflict with WP-CLI. Create wp-content/mu-plugins/update-policy.php:

    <?php
    /**
     * Plugin Name: Update policy
     * Description: Site update rules. Owner and date: write them here.
     */
    
    // Stop auto-updates for one plugin only
    add_filter( 'auto_update_plugin', function ( $update, $item ) {
        if ( isset( $item->slug ) && 'woocommerce' === $item->slug ) {
            return false;
        }
        return $update;
    }, 10, 2 );
    
    // Or stop all theme auto-updates
    // add_filter( 'auto_update_theme', '__return_false' );

    Know what returning false does. The handbook says it also blocks plugin and theme updates pushed by the WordPress.org security team. Don’t put update rules in your theme’s functions.php either. A theme switch or update can remove them without anyone noticing.

    Why updates still happen after you switched them off

    Usually something other than your setting is in charge. Check these in order.

    A forced security update

    WordPress.org can push an update for a critical vulnerability even when your toggles are off. In a 2024 WordPress.org thread, a site owner reported plugins updating with auto-updates disabled. The replies explained that security updates can be forced, and a moderator advised against overriding them when a flaw is being actively exploited. If the surprise update was a security release, the system did what it was built to do.

    Your host runs its own updater

    Managed hosts often update plugins from their own dashboard, outside WordPress. Some do it with a must-use plugin, which keeps running when you deactivate everything else. A GitHub issue logged in October 2026 shows Hostinger’s Smart Auto Updates MU plugin (v1.0.8) registering automatic_updater_disabled as true and auto_update_plugin as false. That is the opposite problem: settings switched off by the host, not by you.

    In a 2023 WordPress.org case, Site Health warned that background updates weren’t working because the automatic_updater_disabled filter was enabled. The owner’s wp-config.php didn’t contain it. The source was a “Disable Auto Updates” MU plugin the host had installed. The owner waited days for it to be removed.

    An update-management plugin

    Plugins that manage updates keep their own rules. Running one next to a host updater gives you two policies that disagree. Choose one system and turn off the other.

    To find which layer is in control:

    1. Check the item’s toggle on the Plugins or Themes screen.
    2. Look in your host’s control panel for anything labelled automatic or plugin updates.
    3. Open wp-content/mu-plugins/, or Tools → Site Health → Info → Must Use Plugins.
    4. Check for an update-management plugin in your plugin list.
    5. Search wp-config.php for the two constants above. Old sites often still have them, and nobody remembers why.

    If it’s still unclear, ask the host directly whether it updates plugins or core itself.

    When updates aren’t running at all

    Sometimes nobody switched anything off and updates still don’t happen. WordPress.org’s documentation says plugin and theme auto-updates rely on WP-Cron and run twice a day. If the scheduler or the file system is broken, no setting will help.

    Open Tools → Site Health and read the Status tab. The WordPress.org Health Check handbook lists the checks that matter here: failed scheduled events, background updates and loopback requests. Then work through the causes:

    • Cron. If DISABLE_WP_CRON is set in wp-config.php, a real server cron job has to replace it. Without one, scheduled updates never run.
    • Permissions. If WordPress asks for FTP credentials, it can’t write files as the web server user. Ask the host to fix ownership. Don’t loosen permissions across the site.
    • Disk space. A full disk stops updates from unpacking. Old backup archives are a common cause.
    • A leftover .maintenance file. If the site says “Briefly unavailable for scheduled maintenance”, WordPress.org’s troubleshooting FAQ says to delete .maintenance from the WordPress root. Deleting it brings the site back. It doesn’t finish the update, so run the update again.

    If an update broke the site, fix that one thing

    Switching everything off hides the symptom and leaves the cause in place. Find the component first. WooCommerce’s self-service guide gives the standard routine: switch to a default theme, deactivate everything except WooCommerce and the extensions involved, then reactivate them one at a time.

    Often the cause is narrow. In an October 2026 WordPress.org review, a site owner said a form plugin’s auto-update took their site down because the new version required PHP 8.3 and the server ran PHP 8.0. Turning off every update wouldn’t have fixed that. Upgrading PHP, or holding back that one plugin until the server could be upgraded, would have.

    Roll back only the plugin that broke, and only until a fix ships. The Developer Handbook warns that older code can bring back security holes and cause database version problems. When a fixed version is out, turn that plugin’s auto-updates back on. Rolling back one plugin also keeps every order and edit made since your last backup. A full restore from backup throws those away.

    Stores need extra care. WooCommerce’s update guide says some releases need a separate database update after the files update, and you can follow its progress under Scheduled Actions. The guide also says to back up the database and wp-content, test on staging, then check product pages, cart, checkout, payment, shipping, tax and email. It suggests a monthly cadence for most stores, with security fixes applied sooner.

    The policy most practitioners settle on

    WordPress.org threads and Reddit discussions keep landing on the same compromise:

    • Keep minor core releases automatic, along with your security and backup plugins.
    • Turn off auto-updates only for the plugins that can cost you money when they change: payments, checkout, page builders, heavily customised features.
    • Update those by hand on a named day. Take a backup first, use staging if your host offers it, and update one at a time, never with “Update all”.
    • After each update, load the homepage, submit a form and run a test checkout.
    • Write down what is switched off, where, and who owns the manual updates.

    WordPress.org has also started delaying some releases on its side. The Plugins Team’s phased release rollout, announced in August 2025, delays automatic updates by 24 hours for plugins that opt in. You can still update by hand during that window.

    If nobody on your team wants to own the manual queue, SiteSelf handles plugin updates on request through chat, then reports what changed and what it checked.

    Frequently asked questions

    How do I turn automatic updates back on?

    Reverse whatever you changed. Click “Enable auto-updates” on the item, delete the constant from wp-config.php, or delete the filter from your MU plugin. Then check Site Health. If it still says background updates are disabled, something else is setting the filter, usually a host MU plugin.

    Why can’t I see the auto-update links on my Plugins screen?

    Check that you run WordPress 5.5 or later. If you do, WordPress.org’s documentation says a host or a plugin may have turned the feature off. Look in wp-content/mu-plugins and in Site Health → Info → Must Use Plugins.

    Why do update notices still show after I turned off auto-updates?

    Stopping automatic installs and hiding update notices are separate things. Turning off auto-updates means WordPress waits for you to click Update. It still tells you an update exists, and you want it to.

    How often do WordPress auto-updates run?

    WordPress.org’s documentation says plugin and theme auto-updates run twice a day by default, through WP-Cron. If WP-Cron is disabled and no server cron replaces it, they don’t run at all.

    Do premium plugins and WooCommerce extensions follow the same toggle?

    The toggle only applies to updates WordPress can find. WooCommerce’s update guide says Marketplace extensions update only when the store is connected to a WooCommerce.com account. Third-party extensions follow their vendor’s own update method. Check those separately, because they fall behind without any warning.

  • WordPress tags vs categories and when to use each

    Key takeaways

    • Only categories can have parent and child terms. Every post ends up in at least one category, because WordPress files it under the default category (set in Settings > Writing) if you pick none.
    • A tag is worth creating only if it will be used on several posts across different categories. A tag used on one post creates an archive page with almost nothing on it.
    • Google has no rule about indexing category or tag pages. Judge each archive on whether it’s useful, and use noindex to keep it out of results. Blocking it in robots.txt doesn’t do that.
    • Deleting a category never deletes its posts. WordPress moves them to the default category, but the old archive URL still needs a redirect.
    • In WooCommerce, use product categories for departments, product tags for labels that span departments, and attributes for anything shoppers filter by.

    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.

    CategoriesTags
    StructureHierarchical: a parent such as Services with children such as Design and MaintenanceFlat, no parents
    RequiredEffectively yes: a post with no category goes into the default categoryNo, entirely optional
    JobSays where a post belongsSays what else the post is about
    In the block editorA checkbox list, which encourages picking an existing termA text field, which makes a new term one keystroke away
    Archive URL (default)/category/services/design//tag/gluten-free/
    Healthy numberA short list that rarely changesGrows slowly, and each tag is used on many posts

    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

    Can tags have a hierarchy?

    No. Only categories support parent and child terms. If you need nested subjects, use child categories. If the built-in pair doesn’t fit, as with recipes grouped by meal and by dietary need, register a custom taxonomy for each grouping.

    Do I have to use tags at all?

    No. Tags are optional, and plenty of well-run sites use categories only. Use tags if you’ll apply them consistently across sections and show them to readers. Otherwise they only add archives.

    Do tags help SEO?

    Not by themselves. The label carries no ranking value. A tag archive can bring in visitors if it’s a useful collection with real content, and a thin one only gives crawlers more pages to process.

    Why can’t I see the category and tag boxes in the editor?

    In the block editor they’re in the right-hand sidebar under the Post tab, often in collapsed panels. Check the editor’s Preferences to make sure the panels are enabled. If they’re still missing with a default theme and no plugins active, the install itself may be modified, which is worth raising with your host.

    Can I change the slug of a category without losing traffic?

    Yes, if you add a 301 redirect from the old archive URL to the new one when you make the change. Changing only the display name leaves the URL alone. Our guide to what a WordPress slug is covers where to edit each one.

    Can Pages have categories and tags?

    Not by default. Categories and tags apply to posts. A plugin or a few lines of code can add them to Pages, but first ask whether a page hierarchy (parent and child pages) already does the job.

  • Chatbot vs live chat on a WordPress site

    Key takeaways

    • In Comm100’s 2025 benchmark, chatbots handled 73.8% of chats in 2024 but resolved only 45.8%. The resolved share barely moved from the year before.
    • Handing a chat from the bot to a person is a setting, usually with separate options for staffed and offline hours. Turning on AI does not mean a person sees the questions the bot could not answer.
    • The WooCommerce AI Assistant is an admin tool that shoppers never see. The storefront chatbot is a separate product, the AI Support Assistant.
    • When a widget shows for the admin but not for visitors, the usual causes are cache and JavaScript delay or defer settings. Check those before the theme or the host.

    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.

    RequestBetter first responderWhy
    Opening hours, shipping policy, returns windowBotThe answer is already written on your site
    Order status lookupBot, if it can read ordersOne fact, a clear finish, no judgment
    Inquiry outside business hoursBot that collects name, contact and job detailsNobody is there to answer, but the lead is still worth keeping
    “Will this work for my situation?”Bot first, person on buying intentPricing and fit questions are where sales are won or lost
    Refund, wrong charge, complaintPersonNeeds account access, a decision and a believable apology
    Anything the bot answered wrong once alreadyPersonA second guess costs more than a short wait

    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

    Can a chatbot replace live chat completely?

    Not reliably. Billing disputes, account-specific problems, exceptions and upset customers need a person. Comm100’s figures show bots resolving under half of what they handle. A bot with a clear route to a person is the realistic setup.

    Will a chat widget slow down my WordPress site?

    It adds third-party JavaScript, so it can. There is no current, independent benchmark comparing widgets, and older forum reports no longer describe how vendors load their scripts today. Test your own pages in PageSpeed Insights with the widget on and off.

    Does a chat widget hurt SEO?

    Not by itself. The risks are narrower. Content that exists only inside chat is not indexed as page content, and auto-opening dialogs that cover the page go against Google’s guidance on intrusive dialogs. Keep answers on the page and let visitors open the chat themselves.

    Should I use the plugin or paste the vendor’s code?

    Either works, but never both. Running the plugin and pasted code at once loads the widget twice and causes display problems. The plugin is easier to remove later. Pasted code depends on the theme calling wp_footer(), or on a code snippets plugin that adds it for you.

    Why don’t shoppers see the WooCommerce AI Assistant?

    It is built for store admins and does not appear on the storefront. The customer-facing option is the AI Support Assistant. You enable it separately and configure it with an AI provider, a knowledge base and product information.

    Is chat worth it on a low-traffic site?

    Sometimes not. If visitors send a handful of different questions a month, a clear FAQ, a contact form and a visible phone number may serve them better. Chat pays off when the same questions keep coming back, or when after-hours inquiries would otherwise be lost.

  • Landing page design best practices for WordPress

    Key takeaways

    • Pick one goal and repeat its button at the top, after the persuasive content and at the bottom. A second, different goal competes with the first.
    • Unbounce’s 2024 benchmark found pages written at a 5th to 7th grade level converted at 11.1%, against 5.3% for professional-level copy. That is a correlation, not proof that simpler copy causes the lift.
    • Don’t lazy-load the hero image. It is usually the largest element on the page, and Google counts a Largest Contentful Paint of 2.5 seconds or less as good.
    • In a block theme, a Front Page template overrides Settings > Reading. That is why some homepage changes appear to do nothing.
    • A checkout that looks right in the editor proves nothing until the page is assigned under WooCommerce > Settings > Advanced and you have placed a test order on the storefront.

    You pay for the traffic. The page looks polished. The leads don’t come. When practitioners audit pages like this, they rarely blame the color palette. They find one of three problems: visitors can’t tell what the offer is, nothing nearby gives them a reason to trust it, or the page is broken in a way nobody saw from the editor.

    The first two are design problems. The third is mostly a WordPress problem, and it is the one most best-practice lists leave out. This article covers all three. If you haven’t built the page yet, start with how to build a landing page in WordPress and come back once you have a draft.

    Why one goal beats one button

    A landing page asks the visitor to take one action. Book a consultation, start a trial, or buy the bundle. If it also offers the newsletter, the blog and a careers link, each one is a decision the visitor has to make before they act.

    “One goal” doesn’t mean one button. WordPress.com’s product landing page guide recommends putting a call to action at the top, another after the persuasive content and another at the bottom. That is the same goal three times, placed where people make up their minds. Two different goals on one page compete with each other.

    Write the goal down before you touch the editor: “A qualified patient requests a consultation.” That sentence tells you what to measure. Count completed requests, not clicks on a button that opens a calendar.

    What the first screen has to answer

    Before anyone scrolls, the first screen should say what this is, who it’s for and what to do next. In practice that means four things:

    • a headline that names the outcome or the service
    • a supporting line with the detail that qualifies the visitor, such as location, price range or availability
    • an image of the actual product or result, not a mood photo
    • a button that describes what happens when it’s clicked

    “Check availability” and “Request a quote” are different promises. Choose the label that matches where the button goes. If a button says “Check availability” and opens a general enquiry form, change the label or the destination. “Learn more” says nothing at all.

    The headline also has to continue whatever brought the visitor in. If the ad said “emergency roof repair in Leeds”, that phrase belongs at the top of the page, not three sections down below a general company introduction. Practitioners call this message match. In community threads it’s one of the most common explanations for a page that converts badly.

    In the block editor, check the Cover or Group block that holds the hero. A large minimum height, heavy padding or vertical centering can push the button below the first screen on a phone, even when it fits on a laptop.

    How simple should the copy be?

    Simpler than you think, and as long as the offer needs. Unbounce’s 2024 Conversion Benchmark Report covered more than 41,000 landing pages. Pages written at a 5th to 7th grade reading level converted at 11.1%, compared with 5.3% for professional-level copy. Difficult words, reading time and word count all correlated negatively with conversion.

    These are correlations on Unbounce-hosted pages. They aren’t proof that cutting words causes the lift. A newsletter signup needs a headline and a field. An unfamiliar service at a high price needs proof, details and an FAQ that answers the objections people actually raise. Cut words that don’t explain the offer, and keep the ones that do.

    The same report puts the median conversion rate across industries at 6.6%, with industry medians ranging from 3.8% for SaaS to 12.3% for events and entertainment. Compare yourself with your own industry and offer, not with the overall figure.

    Where proof and forms belong

    Specific proof works better than general praise. “They explained our VAT position in one call and onboarding took a week” tells a prospect something. “Great service” doesn’t. Put proof next to the place people hesitate, usually beside the button or the form. A testimonials section at the very bottom doesn’t do that job. Use names, photos and logos only when you have permission.

    A form should ask only for what you need to qualify the lead and reply. Keep a field if its answer changes how you follow up. Remove it if it’s there because the template had it. The W3C’s forms tutorial says every control needs a real label, so a placeholder that disappears as the visitor types isn’t enough. Error messages should name the field and say how to fix it.

    Then send a real test enquiry from your phone. Check that the right inbox receives it, that the visitor sees a useful confirmation, and that spam protection doesn’t silently reject real submissions. A form that looks perfect but loses enquiries is broken.

    Trust also depends on what you forget to remove. Auditors regularly find Lorem ipsum, demo pages left in the sitemap and template phone numbers still linked from the call button on live pages. Read the published page from top to bottom before any traffic arrives.

    The same thinking applies to navigation. Remove the journeys that compete with the goal. Keep the information people need before they trust you: contact details, policies and the cart on a shop. Stripping the header and footer completely suits a short paid campaign better than an unfamiliar professional service.

    Design for the phone, then check the desktop

    In Unbounce’s dataset, 83% of visits came from mobile, while desktop converted 8% better on average. Most of your visitors are probably on a phone, and the phone is where the friction is. Design for it first.

    Page builders make this harder than it looks. Elementor’s responsive settings cascade from desktop to tablet to mobile, so a margin set for desktop carries down unless you override it. “Hide on mobile” fixes one screen by removing content from another, and Google indexes the mobile version of your page. Our guide to making a mobile-friendly website covers the theme and builder settings in detail.

    Two accessibility checks catch a lot of mobile breakage. WCAG 2.2 requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text. It also requires content to reflow at a width of 320 CSS pixels without losing information or function. Test on a real phone with the keyboard open, and watch for a sticky bar or cookie banner covering the button.

    Why the hero image decides your load time

    On most landing pages the hero image is the largest element on the first screen, so it sets your Largest Contentful Paint. Google’s Core Web Vitals treat LCP of 2.5 seconds or less as good, along with INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile of real visits.

    The most common self-inflicted delay is a “lazy-load all images” setting in an optimization plugin. web.dev’s LCP guide explains that lazy-loading the LCP image delays the moment the browser starts fetching it. Turn off lazy loading for the hero and keep it for images further down. Put the hero in the page HTML as a real image rather than a CSS background, give every image a width and height so the button doesn’t jump while the page loads, and compress the file. Our guide to optimizing pictures in WordPress covers formats and sizes.

    Speed shows up in results. Portent’s 2022 study found that a B2B site loading in one second converted three times better than one loading in five seconds. That is an association across a limited set of sites, but it points the same way as everything else.

    Measure the live, cached page, not your staging copy. Staging often runs without caching and looks worse than production. Run PageSpeed Insights more than once, and remember that purging the cache slows the site for a while as pages rebuild.

    WordPress checks that catch pages that look finished

    A page can be well designed and still not work. These checks come from official documentation. Each one fails without warning.

    CheckWhereWhat goes wrong
    Which template is servedAppearance > Editor > TemplatesIn a block theme, a Front Page template is used for the front page whatever Settings > Reading says.
    Header and footerElementor page settingsCanvas removes the theme header and footer. Full Width keeps them. Check the published page, not the editor.
    Old Elementor tutorialsElementor ProElementor’s separate Landing Page feature is deprecated and unsupported as of Pro 3.27. Build on a regular page instead.
    IndexingSEO plugin settings, robots.txtnoindex keeps a page out of Google. Blocking the page in robots.txt can stop Google from seeing that noindex tag.
    CheckoutWooCommerce > Settings > AdvancedA custom checkout page that isn’t assigned here won’t work as checkout, however good it looks.
    Shared templatesSite EditorEditing a shared template, including WooCommerce’s Single Product template, changes every page that uses it.

    Run the checks in this order: confirm which page and template WordPress is actually serving, look at it at phone width while logged out, submit the form or place a test order on the storefront, then measure the live page. Logged-in admins often see different banners and a fresher cache than visitors do. Website layout and design on WordPress explains how global styles and templates affect individual pages.

    If you’d rather describe the change in chat and have it made on the live site, SiteSelf handles design changes on existing WordPress sites, though it refuses pages owned by Elementor, Divi or Beaver Builder and tells you why.

    When A/B testing is worth it

    Test after the basics are right, not instead of them. A clearer headline won’t help much if the form drops submissions. Once the offer, the first screen and the plumbing are sound, test one thing at a time: the headline, the button or the hero image.

    Many small sites don’t have the traffic for a meaningful test. In an Unbounce and Ascend2 survey of 264 marketers at businesses with 500 or fewer employees, reported by MarketingProfs, 41% named low traffic as their biggest testing challenge. With limited traffic, don’t declare a winner after a handful of enquiries. Look at form errors, the questions customers ask, session recordings used with proper consent, and whether the traffic was ever a good match for the offer.

    Pages also decay after launch. Offers expire, prices change, forms stop reaching anyone and mobile layouts drift after updates. Put a date in the calendar to reread the page and resubmit the form.

    Frequently asked questions

    Do I need a page builder plugin for a landing page?

    No. The block editor and a suitable template can produce a clean, fast landing page. Builders add visual controls and ready-made layouts, and they also add weight and their own settings to maintain. Our article on whether you need a landing page builder walks through the tradeoff.

    What is a good landing page conversion rate?

    Unbounce’s 2024 median across industries was 6.6%, with industry medians from 3.8% to 12.3%. Your rate depends on your traffic, your offer and what you count as a conversion. Compare yourself with your own past results and your industry, not one headline number.

    Should I remove the header and footer?

    Remove what competes with the goal. Keep contact details, legal links and anything a cautious buyer would look for. In Elementor, Canvas removes both the header and footer, and Full Width keeps them, so pick the one that matches what you actually want to keep.

    Can my landing page be my homepage?

    Yes. Set it under Settings > Reading. If you use a block theme with a Front Page template, edit or remove that template, or your choice won’t take effect. Our guide to editing your homepage covers both cases.

    Is Elementor bad for landing page speed?

    It depends on the page. Heavy addons, nested sections and unoptimized hero images add weight, but a lean Elementor page can still pass Core Web Vitals. Measure your actual live page in PageSpeed Insights instead of going by the builder’s reputation.

    How many form fields should I use?

    No authoritative number exists. Ask for what you need to qualify the lead and reply, and drop the rest. Practitioners report gains from removing even one field, but those are single anecdotes, not rules.

  • Problems with WordPress today and how to fix them

    Key takeaways

    • Self-hosted WordPress has no central server that can go down. If your site fails, the cause is your site, your host, your domain or your network.
    • Plugin and theme incompatibility after an update is the most common trigger. Some conflicts only appear when two specific plugins are active together, so disabling everything at once can hide the cause.
    • Patchstack counted 11,334 new WordPress ecosystem vulnerabilities in 2025. 91% were in plugins and 46% had no developer fix at disclosure.
    • Read the error log before you raise the memory limit, change PHP or restore a backup. Each of those can hide the real cause or overwrite new orders.
    • On a stuck WooCommerce checkout, check WooCommerce > Orders before you retry, because the order may already exist. A staging copy can still charge real payments.

    When a WordPress site breaks today, WordPress itself is rarely the cause. The cause is usually one plugin, one theme, the PHP version, a cache or the host, and each of these fails in its own way. Patchstack’s report on 2025 found 91% of new WordPress vulnerabilities in plugins. Everyday breakage follows the same pattern: the trouble is in the layers around core.

    This matters because your first move decides how long the fix takes. Find the failing request or component before you change any settings. Our guide to fixing WordPress issues without guessing covers the method in depth. This page matches today’s common symptoms to the first safe step for each.

    Is WordPress down, or is it just your site?

    It is almost always just your site. Self-hosted WordPress has no central server that can go down for everyone. WordPress.com is a separate hosted service with its own status page, and that page tells you nothing about a site on your own hosting.

    Rule out the cheap explanations before you touch plugins:

    • Load the site on mobile data instead of your office Wi-Fi.
    • Confirm the domain hasn’t expired and the hosting bill is paid.
    • Check your host’s status page.

    Each of these can produce the same blank page or timeout as a broken plugin, and no amount of plugin testing will fix them.

    Which problems turn up most, and what to do first

    Nobody publishes a reliable count of which WordPress problems are most common. The table below follows the order that WordPress.org’s documentation, WooCommerce’s docs and the support forums consistently point to. Find your symptom before you change anything.

    SymptomUsual causeFirst safe step
    Something broke right after an updatePlugin or theme incompatibilityRoll back or disable that one component, on staging if you can
    “There has been a critical error on this website”PHP fatal error in a plugin, theme or custom codeRecovery Mode email, or the error log
    White screen or 500 errorPHP fatal error, .htaccess or memoryRead the error log
    “Allowed memory size … exhausted”The process named in the errorFix that process before you raise the limit
    Changes not showingA cache layer still serving the old copyPurge every layer and test in a private window
    Checkout stuck on a spinnerA failed background requestBrowser Network tab, then check Orders
    “Error establishing a database connection”Wrong wp-config.php details, or the database serverCheck the credentials, then ask the host
    Every post 404s, homepage loadsStale rewrite rulesSave Settings > Permalinks

    The site broke after an update

    This is the problem people hit most often. WordPress.org’s Recovery Mode documentation says fatal errors often come from an incompatible or faulty plugin, theme or custom code, and updates are when those incompatibilities show up. An update can break the whole site, only wp-admin, or a single feature such as checkout, a form or a layout.

    Start with what changed. If one plugin updated this morning and checkout broke this afternoon, roll back or deactivate that plugin first. If nothing obvious changed, run a conflict test the way WooCommerce documents it:

    1. Switch to a default theme.
    2. Disable all plugins.
    3. Turn them back on one at a time, and repeat the exact action that failed after each one.

    The common trap is disabling everything and calling the site fixed. Some conflicts only happen when two specific plugins run together. A blanket disable brings the site back but hides which pair caused the problem.

    One store owner on the WordPress.org forums handled this well. They updated a cookie consent plugin and a few others on staging, and guest checkout stopped working. Testing showed the consent plugin was blocking a WooCommerce script. A settings exception worked around it until the plugin’s author released a fix. The live store never saw the failure.

    If WordPress said the update itself failed, that’s a different problem. See why WordPress updating failed.

    “There has been a critical error” means PHP stopped

    This message means a PHP fatal error, almost always from a plugin, theme or code snippet. WordPress emails the admin address a Recovery Mode link, which pauses the failing component for your login session only. Visitors still see the error until you deactivate or fix that component. WordPress’s documentation calls deactivation a temporary fix, not the real one.

    The email often never arrives, especially when the admin address is an inbox nobody reads anymore. In that case, open your host’s file manager or connect over SFTP and rename the suspect plugin’s folder in wp-content/plugins. WordPress then treats that plugin as deactivated. The error log names the file that failed, which tells you which folder to rename. Our guide on how to fix a WordPress fatal error shows how to read that log.

    A white screen or a bare 500 is often the same failure with error display turned off. WordPress’s common-errors handbook lists .htaccess, plugins, the theme and memory limits as causes of a 500. The log tells you which one it is. See fixing a server error 500 on WordPress.

    Memory errors: fix the process, not the limit

    When the log shows “Allowed memory size of … bytes exhausted”, visitors usually see a critical error, a blank page or a 500. Kinsta’s documentation advises fixing the process named in the error rather than simply raising the limit. Raising WP_MEMORY_LIMIT in wp-config.php only helps when the limit really is the problem. Your host may also enforce a lower ceiling than WordPress requests, so the edit can do nothing at all.

    If the error names a plugin file, that plugin is your first suspect. Before you edit anything, ask your host what memory limit your plan actually allows.

    Changes not showing usually means a cache is still serving the old page

    A WordPress site can have five caches: a caching plugin, the host’s server cache, an object cache, a CDN and the browser. Clearing one doesn’t clear the others. Purge each layer you have, then check the page in a private window.

    Stores have a second cache problem. WooCommerce’s documentation says the Cart, Checkout and My Account pages usually need to be excluded from page caching because their content is specific to each shopper’s session. If they get cached, those pages can display incorrectly or stop working.

    A stuck checkout spinner means a request failed

    WooCommerce’s documentation says the spinner alone doesn’t tell you the cause. To find it:

    1. Open your browser’s developer tools and go to the Network tab.
    2. Filter by Fetch/XHR.
    3. Place a test order and find the request that failed.

    The failed request points to the layer at fault:

    • 403: a firewall, security rule or authorization check rejected the request.
    • 500: a PHP fatal error or server failure. Check the error log.
    • HTML or a redirect where JSON should be: a cache, security layer, proxy, redirect or PHP warning changed the response.

    The same document gives three warnings:

    • Check WooCommerce > Orders before you retry “Place order”. The order may already exist.
    • A staging copy can still charge real payments, send email and fire webhooks unless you turn those connections off.
    • Don’t switch between the Checkout block and classic checkout as a first step. The switch can hide the original incompatibility.

    “Error establishing a database connection”

    WordPress’s handbook gives two kinds of cause:

    • A wrong database name, user, password or host in wp-config.php.
    • A problem at the host, such as a database server that is down or over its quota.

    If you haven’t changed the credentials and the error comes and goes, suspect the database server.

    Extreme cases exist. One site on the WordPress.org forums had intermittent connection errors on shared hosting. Replies traced them to a wp_options table that had grown to about 32 GB, which caused table locking. The right fix in a case like that has three parts: find the plugin writing the data, back up, and have the host look at the database. A cleanup plugin that removes the data but leaves the plugin writing it only buys a few weeks.

    Every post 404s but the homepage loads

    This usually means the rewrite rules are stale. Go to Settings > Permalinks and click Save Changes without changing anything. That rebuilds the rules.

    If that doesn’t help, check two things. The server may not have Apache’s mod_rewrite module enabled, which WordPress.org’s troubleshooting FAQ lists as a cause. Or a page and a custom post type may share a slug. If you aren’t comfortable editing .htaccess, ask your host.

    Why the plugin security problem keeps getting bigger

    Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than in 2024:

    • 91% were in plugins and 9% in themes. Only six were in core, all low priority.
    • 46% had no fix from the developer by the time they were made public.

    Treat these numbers with care. Patchstack sells security products. Other security companies count vulnerabilities differently and get different totals. Some of the growth comes from more researchers looking. A vulnerability count is not a count of hacked sites. What every source agrees on is that the risk is in plugins, so an up-to-date core does not mean an up-to-date site.

    Site owners feel this too. In WordPress.org’s 2023 Annual Survey, the top frustration was “too many plugins (finding the right one)” at 18.6%. Security followed at 16.4%, slow performance at 16.2%, and maintenance and updates at 12.3%.

    The practical response is routine work:

    • Delete plugins you don’t use.
    • Keep the rest updated.
    • If a plugin has a publicly known flaw and no fix, deactivate or replace it.

    If you suspect a hack, WordPress security issues and how to fix them explains how to tell a compromise from an ordinary error.

    Which quick fixes make things worse

    Each of these feels like progress and often isn’t:

    • Raising the memory limit before reading the log. It hides a faulty plugin, and the host may ignore the new value anyway.
    • Clearing one cache and assuming the job is done. The CDN or server cache can still serve the old page.
    • Disabling the security plugin to see if it helps. Confirm that it blocked the request first. Otherwise you have removed protection and learned nothing.
    • Disabling plugins on a live store at a busy hour. Customers lose the features those plugins provide while you test.
    • Changing PHP because the site is slow. A PHP change is a compatibility project, not a speed fix. Test it on staging.
    • Restoring a full backup first. A restore overwrites every order, form entry and edit made since the backup was taken. Rolling back one plugin keeps them. If you do need a restore, how to restore a WordPress site from backup covers what to protect first.
    • Changing several things at once. If the site comes back, you won’t know which change fixed it.

    When to stop and get help

    Stop doing it yourself in any of these situations:

    • You are locked out of both wp-admin and your hosting files.
    • A live checkout is failing and you have no staging copy you can safely test payments on.
    • There are signs of a compromise: redirects you didn’t add, admin users you don’t recognise, or browser warnings.
    • Database errors continue even though the credentials are correct.

    Whoever takes the job needs the same information either way:

    • the URL;
    • the exact action that fails;
    • when it last worked;
    • what changed in between;
    • the relevant lines from the error log.

    Get the scope and any extra charges in writing before work starts. “Investigation” means different things to different providers.

    If you’d rather describe the symptom in chat than trace it yourself, SiteSelf’s agent can do WordPress troubleshooting and bug fixes on your existing site, using hosting access for file and code work, and reports what it changed and checked.

    Frequently asked questions

    How do I find which plugin is causing the problem?

    Disable all plugins, then turn them back on one at a time, repeating the exact action that failed after each one. Switch to a default theme too if the problem survives. Do this on staging for a store, because disabling plugins on the live site removes features customers rely on.

    Does updating WordPress fix every security issue?

    No. Core updates cover core. Plugins and themes update separately. PHP is updated on the server by your host. A dashboard that says everything is up to date tells you nothing about the PHP version running your site.

    Should I turn on automatic plugin updates?

    For well-maintained plugins on a simple site, auto-updates close security holes faster than you would by hand. On stores and sites with custom layouts, an update can break checkout or a template without warning, so test those updates on staging first. Either way, keep a backup you know you can restore.

    Why did my site suddenly slow down?

    “Slow” is a symptom with several possible causes: a plugin, large images, the host, caching, the theme, external scripts or the database. Measure the page with PageSpeed Insights before you change anything or pay for optimisation. Turning plugins off doesn’t always reveal the cause.

    Can two plugins that work fine on their own break the site together?

    Yes. Some conflicts only appear when two specific plugins, or a plugin and a theme, are active at the same time. That’s why the conflict test turns plugins back on one at a time instead of judging each plugin alone.

    Can my host fix it?

    Hosts handle server problems: database outages, memory ceilings, PHP versions and missing server modules. Most won’t debug a plugin conflict, and some charge for investigation. Ask your host to confirm your account’s limits and check the server logs, then take that information to whoever fixes the site.

  • Creating landing pages on WordPress, step by step

    Key takeaways

    • Build on Pages > Add New. Elementor’s separate Landing Page feature is deprecated as of Elementor Pro 3.27, and those legacy pages can’t be picked as the homepage.
    • Pick the layout on purpose. Elementor’s Canvas removes the header, footer and sidebars, and Full Width keeps the header and footer. Editing a shared template changes every page that uses it.
    • A form passes only when a test entry reaches the inbox. Every field needs a visible label whose for value matches the input’s id, as the W3C’s accessibility tutorials describe.
    • Unbounce’s 6.6% median conversion rate covers many platforms and industries. Compare against your own baseline, split by device and traffic source.
    • Near-identical pages for each city or keyword can fall under Google’s doorway abuse policy. Each page needs its own reason to exist.

    WordPress has no landing-page content type. A landing page is an ordinary Page with one job: get a visitor from an ad, an email or a post to take one action. You don’t need a special plugin, and you shouldn’t use the special feature some older tutorials describe. Elementor’s separate Landing Page feature is deprecated as of Elementor Pro 3.27.

    The build is the easy part. Practitioners on Reddit and the WordPress.org forums keep naming the same hard parts: the copy, the scope, mobile behaviour, testing the form, and keeping the page in step with the offer once it’s live. This guide covers the whole job, from the goal to the launch checks. If you’re still choosing a tool, our guide to building a landing page in WordPress compares the block editor with page builders.

    What should you decide before opening the editor?

    Decide on one action and write it down in a single sentence. For example: “This page helps homeowners in our area request an interior painting quote.” If you can’t write that sentence, the page will try to do three things and none of them well.

    Add three facts to the sentence. Where do visitors come from? What does the ad or email promise? What does your team need from the visitor to reply properly? Those answers decide the headline, the form fields and the slug.

    Also decide what counts as a good result. A quote request from outside your service area is still a completed form, but it isn’t work. Track qualified enquiries next to raw submissions. Otherwise a page can look successful while it fills your inbox with leads you can’t serve.

    What do you need before you start?

    • Access: an Editor or Administrator account. To set the page as the homepage, change a template or install a form plugin, you need Administrator.
    • Copy: a headline, three or four benefits, one or two pieces of real proof, and answers to the questions that hold buyers back. Write the copy before you build. Writing it during the build is what turns a three-hour page into a three-day page.
    • Images: one hero photo of real work, sized for the web.
    • A form tool your site already uses, if it has one.

    How to create the landing page

    1. Create the page. Go to Pages, then Add New. Give the page a title and set a short slug that uses the words from the ad, such as interior-painting-quote. If you change the slug after the campaign starts, every link already sent out breaks unless you add a redirect.
    2. Choose the layout for this page only. This is the setting behind most “my menu disappeared” and “why is the header still there” questions, and it depends on your theme:
      • In a block theme, assign a custom template (Learn WordPress builds one without header navigation).
      • In a classic theme, pick the blank or full-width template if the theme provides one.
      • In Elementor, open Page Settings, then Page Layout. Canvas removes the header, footer and sidebars. Full Width keeps the header and footer. Elementor’s Single Page templates apply only to pages on the Default layout.
      Don’t edit a shared template to change one page. The WordPress Theme Handbook warns that a template change affects every page that uses it.
    3. Write the hero to match the ad. An ad about interior painting should land on a headline about interior painting, not “Transform your space.” Say who the page is for, what they get and what to do next. Put the button beside that text. Use the same button wording (“Get a quote”) here and on the form’s submit button.
    4. Add benefits, proof and objections. The Learn WordPress landing page lesson lists a hero with a call to action, benefits and social proof as the core sections. Place proof near the button, not three screens below it. A named review that mentions the type of job beats an anonymous compliment. Add an FAQ only for real hesitations, and put another button after it.
    5. Build a short, accessible form. For every field, ask whether it changes what your team does next. If it doesn’t, cut it. Give every field a visible label. Placeholder text alone disappears as soon as someone types. The W3C’s guidance on labeling form controls says an explicit label’s for value must match the input’s id. Error messages should say what to fix. Our guide to adding a contact form in WordPress covers the plugin side.
    6. Prepare the images. Compress the hero and check how it crops on a phone. Give informative images short alt text that says what they show. Give decorative images an empty alt="". Don’t leave the attribute out.
    7. Publish, then decide about the homepage. A campaign page can live at its own URL. If it really should replace the homepage, go to Settings, then Reading, choose “A static page” and select it as the Homepage. The Homepage and the Posts page can’t be the same page. In a block theme, check Appearance, then Editor, then Templates, because a Front Page template there can override the Reading setting.

    Selling one product? On a WooCommerce store, add the Single Product block to the page and choose the product. WooCommerce’s documentation says the block displays the product’s image, title, price and add-to-cart controls. A page that only looks like a product page can’t take payment. Keep Cart, Checkout and My Account as separate assigned pages. WooCommerce warns that combining them breaks redirects and payment gateways.

    What does a correct result look like?

    Test the live URL, not the editor preview, while logged out and on a real phone. Logged-in views often skip the cache, so you may see a version your visitors don’t. The page passes when:

    • The first screen shows the offer and the button without zooming, and no popup or cookie banner covers them.
    • The button scrolls to the form, and nothing sticky, such as a header or chat widget, hides the form after the jump.
    • A test submission shows a confirmation and arrives in the right inbox. A success message on screen isn’t proof the email was delivered.
    • Submitting with a required field left empty shows an error that says what to fix.
    • The browser tab shows your real site name, not the default “My WordPress Blog” that practitioners on X keep finding on launch day.
    • The exact URL from the ad, tracking parameters included, opens the page.

    What to do if it did not work

    Most broken landing pages are a setting, not a bug. Start with the symptom:

    SymptomUsual causeFix
    New page shows a 404A cached 404, or rewrite rules that need refreshingPurge every cache layer: plugin, host and CDN. If all pages 404 but the homepage loads, open Settings, then Permalinks, and click Save Changes without changing anything.
    Visitors see an old versionOnly one cache layer was clearedPurge every layer and check in a private window. See why a WordPress page isn’t updating.
    Menu missing, or header still showingWrong layout (Canvas or Full Width)Change the layout on this page only.
    Homepage still shows postsReading setting not saved, or a block theme Front Page templateCheck both.
    Page missing from the Homepage dropdownIt was built with Elementor’s legacy Landing Page typeSave the design as a template, insert it into a regular Page, then assign that Page.
    Elementor editor won’t loadPlugin conflict or PHP memoryTry Elementor’s Safe Mode, deactivate plugins one at a time, and check the memory limit (Elementor recommends at least 256 MB).

    Don’t change the site-wide permalink structure to fix one page. WP Engine’s support docs warn that this can cause 404s across an established site. If the editor error is misleading, check the PHP error log as well as the browser console. In one WordPress.org support thread, “elementor is not defined” turned out to be the host’s 128 MB memory cap. When a fix needs server access or the cause stays hidden after these steps, ask your host or a developer.

    Should you make a version for every city or keyword?

    Only if each version has something real to offer that the others don’t. Google’s spam policies describe doorway abuse as pages that are substantially similar, target similar queries or locations, and funnel users to one destination. Swapping the city name in an otherwise identical page fits that description. One commenter on r/marketing gave a sensible rule: reuse a template when the use cases really are alike, and write separate pages when they differ.

    Paid-traffic variants are different. Pages for an ad test are usually kept out of search anyway. If you run two near-copies, point a rel="canonical" at the main one or redirect the loser when the test ends.

    How do you tell if the page is working?

    Use your own numbers first. Unbounce reports a 6.6% median conversion rate from its Q4 2024 data across about 41,000 pages. That covers many industries and builders, and none of the data is specific to WordPress. A quote request, a sign-up and a purchase are different decisions, so a benchmark is context, not a target.

    Record visits, form starts, submissions and qualified enquiries, split by device and by traffic source. Mobile falling while desktop holds points to layout, overlays or loading. People starting the form and not finishing points to fields or errors. Lots of traffic from one source with weak leads points to the ad’s promise. Change one thing at a time. On a low-traffic site, fix confirmed faults and clear confusing copy, and call untested tweaks guesses.

    Then keep the page current. Practitioners on X describe the same decline: the demo gets imported and the text swapped, and then the price goes stale, nobody tests the form again, and the mobile layout slowly breaks as people add sections. Put a date in the calendar to re-test the form and check the offer. If you’d rather describe each change in chat and have it made and checked on your existing site, that’s what SiteSelf’s page and copy edits cover, though pages owned by Elementor, Divi or Beaver Builder are refused, with the reason.

    Frequently asked questions

    Can I create a landing page without a plugin?

    Yes. A regular Page, the block editor and a blank or custom template are enough. Builders save time with templates and ready-made widgets. They also add weight and make it harder to switch tools later.

    Should a landing page hide the site navigation?

    No controlled evidence settles this. A page for paid traffic with one action usually works best without the menu. A page that people find through search, or that needs to build trust, often benefits from keeping it. Match the page to the traffic source and test.

    How long does creating a landing page take?

    Reports on r/Wordpress range from an hour or two to several days. One developer estimated three to four hours for a simple one-pager. Having the copy and images ready matters more than which tool you pick.

    Does a fast landing page rank better?

    Speed helps visitors, especially on phones, but it is one consideration among many. A well-built page still competes with established pages that have links and history. Treat speed as a requirement for the people who arrive, not as a ranking strategy.

    Can I keep my old Elementor landing pages?

    Elementor says existing landing pages are not affected, but it recommends against using the feature going forward. There’s no rush to migrate. Rebuild a legacy page as a regular Page when you next need to change it, or when it has to become the homepage.

  • How to make a mobile friendly website on WordPress

    Key takeaways

    • Google recommends responsive design, meaning one site and one URL that adapts to the screen. Separate mobile themes like WPtouch take the opposite approach.
    • Most sideways scrolling comes from one element with a fixed width, such as a logo, header column or paragraph. Find that element and fix it. Don’t put overflow: hidden on the whole page.
    • Test at 320 CSS pixels wide, the width WCAG 2.2 Reflow uses. Make tap targets at least 24 by 24 CSS pixels, the WCAG AA minimum.
    • Google retired the Mobile-Friendly Test in December 2023. Use a real phone, Search Console URL Inspection and PageSpeed Insights instead.
    • Speed is a separate job. In HTTP Archive’s 2025 Web Almanac, only 45% of WordPress sites passed Core Web Vitals on mobile.

    The usual complaint is “it looks fine on desktop and awful on my phone.” The usual fix is smaller than people expect. Most themes made in the last several years are already responsive. One element, plugin setting or stale cache is breaking them.

    Google indexes and ranks the mobile version of your pages. Its mobile-first indexing guide calls responsive design the easiest setup to build and maintain: one site and one URL, with the layout adapting to the screen. Everything below works toward that. If you already know which CSS rule you need, our guide to CSS media queries for mobile goes deeper.

    What you need before you start

    You need an admin login and a phone. Most fixes can be made in the block editor or with Additional CSS. Classic themes have Additional CSS under Appearance → Customize. Block themes have it in the Styles panel of the Site Editor. Editing theme files needs a child theme or hosting access. Take a backup first, and try larger changes on a staging copy if your host provides one.

    Step by step: making the site work on phones

    1. Write down what is actually broken

    Open your most important pages on a real phone. That means the homepage, a service or product page, the contact form and, for stores, cart and checkout. For each problem, note the page, the screen width and the symptom, for example: “Contact page, 390px, submit button hidden behind sticky bar.” Then open Chrome DevTools, turn on the device toolbar and set the width to 320px. That is the width WCAG 2.2 Reflow uses. Content should read at that width without scrolling in two directions.

    Google retired the Mobile-Friendly Test and the Search Console Mobile Usability report in December 2023. Older guides still send people to them. Use URL Inspection in Search Console to see how Google renders a page.

    2. Confirm the theme is responsive and the viewport tag is there

    View the page source and look for this line in the <head>:

    <meta name="viewport" content="width=device-width, initial-scale=1">

    Current themes almost always include it. Without it, phones draw a desktop-width page and shrink it. With it, fixed-width elements still overflow, so the tag alone isn’t enough. Don’t add maximum-scale=1 or user-scalable=no. W3C mobile accessibility guidance says to avoid them, because they stop people from zooming.

    If the theme has no mobile layout at all, it’s a theme decision. See the section on rebuilding below.

    3. Find the element that is wider than the screen

    Sideways scrolling, or a white strip down the right side, almost always comes from a single element. Paste this into the DevTools console at phone width:

    document.querySelectorAll('*').forEach(el => {
      if (el.offsetWidth > document.documentElement.clientWidth) console.log(el);
    });

    The usual suspects are a logo with a pixel width, a header split into fixed columns, an image or embed with inline sizes, and an animation that slides in from off-screen. Remove the fixed width, or override it at narrow widths:

    img, video { max-width: 100%; height: auto; }
    
    @media (max-width: 600px) {
      .site-logo img { width: 160px; }
      .wide-box { width: auto; }
    }

    Don’t reach for overflow: hidden on the body. In one WordPress.org support thread about an Elementor header, that rule removed the side margin but clipped the mobile menu down to one visible item. If custom CSS has piled up, remove it and add it back one rule at a time until the problem returns.

    4. Use the responsive controls WordPress already has

    In the block editor, select a Columns block and check that “Stack on mobile” is on. WordPress 7.1 adds responsive styles to block themes. You can set a block’s font size, padding and other settings separately for mobile and tablet. Set them per block type under Appearance → Editor → Styles → Blocks, or per block in its Responsive styles view.

    The limits trip people up. Responsive styles only work in block themes. Tablet values don’t carry over to mobile, so set mobile on its own. Some toolbar controls, such as text alignment, still apply at every size. Your theme’s breakpoints may also differ from the defaults. Page builders keep their own per-device settings, and a margin set on desktop may need changing again on mobile.

    5. Check embeds, tables and text inside images

    A responsive page can still hold a video that doesn’t resize. If you control the theme, opt in with add_theme_support( 'responsive-embeds' );. The Block Editor Handbook lists this as an opt-in feature, so it is off by default. Wide tables are one of the exceptions in the Reflow guidance. They can scroll inside their own box while the page stays put:

    .wp-block-table { overflow-x: auto; }

    Text baked into an image shrinks with the image until nobody can read it. Put the words in a Cover block or a heading instead.

    6. Make menus, buttons and forms work with a thumb

    WCAG 2.2 Target Size (Minimum) sets 24 by 24 CSS pixels as the AA minimum for anything people tap, with some exceptions. Treat that as the floor. Bigger and better-spaced is easier. Open and close the menu, then fill in each form with your thumb. Watch for a keyboard or sticky bar covering the submit button, labels that vanish once you start typing, and error messages that appear off-screen. Use type="email" and type="tel" on fields so phones bring up the right keyboard.

    7. Keep the mobile content the same as desktop

    Hiding blocks on mobile is tempting. Google warns that primary content missing from the mobile version, or loaded only after a tap or swipe, may not be indexed. Titles, meta descriptions and structured data should match desktop too. Hide decoration, not prices, contact details or copy. Accordions and tabs are fine as long as the content is in the page.

    Don’t force the desktop layout onto phones either. A WordPress.org volunteer explained the reason to an owner who wanted exactly that: visitors end up zooming and scrolling sideways. Mobile-specific CSS is the better fix.

    8. Test the store pages separately

    A theme can handle blog posts well and still struggle with WooCommerce. WooCommerce’s guide to choosing the right theme says to check every store page, including My Account, cart and checkout. On a phone, choose a product option, change the quantity and get as far as payment.

    9. Clear every cache layer

    “My fix didn’t work” often means “I’m looking at old CSS.” Purge your caching plugin, then your host’s cache, then the CDN, then your browser. Clearing one layer can leave another serving the old version. Our guide on a WordPress page not updating walks through the order.

    10. Treat speed as its own job

    A layout can fit perfectly and still be slow on mobile data. HTTP Archive’s 2025 Web Almanac found that 45% of WordPress sites passed all Core Web Vitals on mobile. Google’s “good” thresholds are LCP within 2.5 seconds, INP below 200 milliseconds and CLS below 0.1.

    Start with images. Resize them to the size they actually display at, use WebP and lazy-load images below the fold. Don’t lazy-load the hero image, because that delays LCP. Then look at third-party scripts and heavy plugins. Our guide to optimizing pictures in WordPress covers the image side.

    What a correct result looks like

    At 320px and on your own phone, nothing scrolls sideways. Text reads without pinching. The menu opens, closes and shows every link. Forms submit and show their errors next to the right field. The store pages work through to payment. URL Inspection shows Google the same content as desktop. A good PageSpeed score doesn’t prove the menu works, and a poor one doesn’t mean the layout is broken. Check both.

    If it still breaks after the fix

    Suspect an optimisation or plugin setting before you suspect the theme. In one TablePress support thread, horizontal scrolling on mobile stopped working because of SiteGround Optimizer’s “Combine JavaScript Data” setting. Turning it off fixed the problem. On a staging copy, turn off one suspect at a time, such as JS combining, CSS combining or animations, and retest after each. Turning an optimisation off can lower your speed score. Keep that tradeoff in mind instead of switching everything off.

    When the theme isn’t worth retrofitting

    Sometimes the theme stacks everything into one column that looks wrong, or it has no mobile layout at all. At that point you are fighting the theme with overrides. Nobody has good data on when rebuilding beats retrofitting. A useful test: if most of your fix list is “override the theme’s layout,” the theme is the problem. If it’s a handful of elements, fix the elements.

    When to stop and get help

    Stop if the fix needs theme files and you have no backup, if checkout is affected, or if you have been turning plugins on and off on the live site for an hour. If you’d rather describe the problem, for example “the menu on the contact page is cut off on phones,” and have someone make the edit and check it, SiteSelf handles website edits through chat. Pages owned by Elementor, Divi or Beaver Builder are refused, and you are told why.

    Frequently asked questions

    Is there a plugin that makes WordPress mobile friendly?

    Not in the sense people hope for. Your theme and CSS decide whether the site is responsive. Plugins like WPtouch serve a separate mobile theme to phones. That is the opposite of the responsive approach Google recommends, and it needs careful cache setup. Mobile menu plugins can fix the menu, but nothing else on the page.

    Do I need a separate mobile version of my site?

    Generally no. Google recommends responsive design because separate mobile setups add ways to fail: redirects to the wrong page, missing content and metadata that doesn’t match. Edits made on desktop also get missed on the mobile copy.

    Is a resized desktop browser good enough for testing?

    It’s good for finding layout overflow quickly. It won’t show the keyboard covering a button, how a tap feels or how the page behaves on mobile data. Check the important pages on at least one real phone before calling them done.

    What text size should I use on mobile?

    No standard sets a single number. Many themes use 16px body text as a sensible default. The test that matters is whether text reflows at 320px and when zoomed without forcing sideways scrolling.

    Will fixing mobile break my desktop layout?

    Not if you put the changes inside media queries for narrow widths, or use the mobile settings in your blocks. Changes made outside a media query apply everywhere. That’s why you should check desktop again after each fix.

  • 504 HTTP code on WordPress and how to fix it

    Key takeaways

    • Each layer has its own limit: nginx, a host proxy, PHP, PHP-FPM, the CDN. In one WordPress.org thread, nginx allowed 300 seconds and the request still died at 60.
    • The action may have finished anyway. A menu save that returned a 504 had saved, and a checkout that timed out still sent its order email, so check before you retry.
    • On a store, look up the payment in your gateway’s records and in WooCommerce → Status → Logs before telling a customer to try again.
    • Raise a timeout only at the layer the logs point to. One user fixed a bulk image job by raising a cPanel proxy timeout from 300 to 1,200 seconds.
    • If many unrelated URLs time out together, look at PHP worker capacity before blaming one plugin.

    A 504 Gateway Timeout means a server that passes requests along, such as nginx, your host’s proxy or a CDN, waited for the server behind it and gave up. RFC 9110, the HTTP standard, defines it like that: a gateway or proxy did not get a timely response from an upstream server it needed. On a WordPress site, that upstream is almost always PHP running WordPress, and behind PHP sits the database or a remote service.

    So the code tells you where the waiting stopped. It doesn’t tell you what was slow. The most common mistake is to raise a timeout before working out which layer gave up and what work was taking so long. If you are seeing 503s as well, our explainer on what a 503 response code means covers the code that looks the most like this one.

    How is a 504 different from a 502 or 503?

    All three are server-side errors, but each one blames a different part of the chain. The table shows where each one sends you first.

    CodeWhat happenedWhere to look first
    502 Bad GatewayThe upstream answered, but the answer was broken or unusablePHP error log, crashed PHP processes
    503 Service UnavailableThe server said it can’t take the request right nowMaintenance mode, overload, resource limits
    504 Gateway TimeoutThe upstream didn’t answer before the gateway’s limit ran outWhich request hung, and which layer ended it
    524 (Cloudflare only)Cloudflare’s own timeout waiting for your originYour origin server, not Cloudflare

    The error page won’t tell you whether your host, a plugin, the database or a payment API was slow. It can also look different depending on who generated it: “504 Gateway Time-out (nginx)”, “Update failed: 504 Gateway Timeout” in the admin, an import plugin’s error line, or a checkout that spins and then fails.

    Why the action may have worked even though you saw an error

    A 504 means the gateway stopped waiting. PHP may keep going after that. In one WordPress.org thread, a menu save returned a 504 after about a minute, but the menu had been updated. In a WooCommerce thread, checkout hung for 60 seconds and showed “Gateway Timeout”, and the order email still arrived.

    That changes what you do next. Don’t refresh a heavy request over and over. Every retry can start another copy of the same slow work, take another PHP worker and make the queue longer. Check what happened first: did the post save, did the import write rows, did the payment go through.

    Step one: find the exact request that timed out

    Most of the diagnosis comes before you change a single setting. Collect these facts while the error is fresh:

    1. Write down the URL, the action and the time. “Saving the main menu at 14:32”, not “the admin is broken”.
    2. Open the browser’s Network panel (right-click, Inspect, Network), repeat the action once and find the red 504 row. Note the request URL, such as /wp-admin/admin-ajax.php, /wp-json/... or ?wc-api=..., and how long it ran before failing.
    3. Work out the scope. One action or many URLs? Admin only, or the front end too? Every time, or only some of the time?
    4. Look at the duration. If failures keep stopping at about the same number of seconds, that number is a configured limit. It points you to the layer that set it.
    5. Get the logs for that timestamp. You need the access log, the error log, the PHP error log and, if you can get it, the database slow-query log. On shared or managed hosting, ask support to match your URL and time against their logs and tell you which component returned the 504.

    Kinsta’s server-errors documentation recommends the same thing: match the time and URL of the failure to the access and error logs. If you want PHP errors from WordPress too, turn on private logging in wp-config.php above the “stop editing” line:

    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', true );
    define( 'WP_DEBUG_DISPLAY', false );

    Errors then go to wp-content/debug.log and visitors don’t see them. WordPress’s debugging handbook says these tools are meant for local or staging sites, so turn them off when you are done. In one Stack Overflow case, reinstalling and deactivating plugins did nothing, and the debug log showed the exact line that was breaking.

    What usually causes a WordPress 504, and the fix for each

    Nobody publishes data on how often each cause happens. The order below follows how often each one turns up as the confirmed answer in WordPress.org, Stack Overflow and Reddit threads. That partly reflects which fixes are easy to report, so treat it as a place to start, not a ranking.

    A plugin doing too much work in one request

    This is the usual cause when the 504 hits one action, especially in wp-admin, and the rest of the site works. Admin requests skip the page cache and run admin-only plugin code, so a slow hook shows up there first. In the Nav Menu Roles thread, deactivating the plugin turned a save that timed out after about a minute into a two-second save.

    Scale can make this worse. A plugin that is harmless on 500 posts can rewrite every post on every dashboard load when you have tens of thousands. One detailed 2026 write-up described a post-ordering plugin doing exactly that. The 504 looked like a failed login.

    Fix: use the Health Check plugin’s troubleshooting mode. WordPress’s support handbook explains that it turns off plugins and switches to a default theme for your logged-in session only, so visitors keep seeing the normal site. Turn plugins back on one at a time until the 504 comes back. Then update, configure, replace or report the plugin. Turning it off for good is a workaround, not a fix.

    A long job running inside a browser request

    Imports, backups, migrations, security scans and bulk image optimization all try to do minutes of work inside one web request. Messages like “Import Error 504 Gateway Time-out” come from this.

    Fix: make the work smaller or move it out of the browser. Kinsta recommends WP-CLI or scripts for imports, exports and bulk operations. Use the plugin’s batch or chunk settings if it has them. For Duplicator, its documentation suggests directory filters, a different database build method or the DupArchive engine, which has a 500 MB limit in the free Lite version. Duplicator’s Max Build Time limits only the plugin’s own build. It does not lift your host’s limits.

    A slow external service

    Some plugins call out to SMTP servers, payment gateways, shipping APIs or licence servers while the page waits. If that service is slow, the whole request waits with it. In the WooCommerce checkout thread, turning off the SMTP plugin made checkout work but stopped all order emails. Trying other SMTP plugins didn’t help. Switching from the SMTP server to a mail API service fixed it.

    Fix: find which remote call is hanging and replace it, cache its result or give it a shorter deadline. Turning off the feature only hides the symptom.

    PHP workers are all busy

    If many unrelated URLs return 504 at the same moment, think capacity before you think plugin. Kinsta’s documentation explains that requests can queue while they wait for a free PHP thread, then time out. Requests that visitors have already abandoned can still be holding workers.

    Fix: find out what is filling the workers, such as uncached traffic, a bot or one slow endpoint called over and over. In one thread, restarting PHP-FPM brought a site back after renaming the plugins folder did not. That restart is a host or server task, and it clears the jam without explaining it. More workers need more memory, so a plan upgrade without a diagnosis can cost more and change nothing. One store on a 6-core, 12 GB plan still had 504s.

    The limit was raised at the wrong layer

    Every layer between the visitor and the database has its own clock, and whichever runs out first sends the error. In one WordPress.org thread, a scan of about 150,000 files kept dying at about 60 seconds. Nginx was set to 300 seconds, and raising PHP’s max_execution_time made no difference. Duplicator’s documentation makes the same point: if PHP limits are already high and the problem continues, the web server’s timeout may be the one cutting the request off.

    LayerSettingWho usually changes it
    PHPmax_execution_timeYou (php.ini or host panel), if the host allows it
    PHP-FPMPool and request time limitsHost or server admin
    Nginxproxy_read_timeout, fastcgi_read_timeoutHost or server admin
    Host proxy (for example cPanel’s)Proxy timeoutHost
    CDNOrigin response timeoutCDN plan and settings

    The nginx documentation gives proxy_read_timeout a default of 60 seconds. It measures the gap between two reads from the upstream, not the total time the response takes. Hosts often change these values, so a repeating 60-second failure is a clue, not proof.

    Fix: raise a limit only at the layer the logs point to, and only for work that really needs the time. In one thread, a bulk image job failed at 60.081 seconds and worked once the cPanel proxy timeout went from 300 to 1,200. Raising limits everywhere just lets slow work hold workers for longer.

    A CDN in front of the site

    A CDN can have a shorter timeout than your origin server. Cloudflare reports its own timeout as 524, not 504, and its “Host Error” page points at your server. A CDN won’t fix a slow origin. It only caches pages for anonymous visitors, which is why the homepage can load fine while wp-admin and checkout time out.

    A 504 at checkout: check the payment before anything else

    On a WooCommerce store, a checkout that times out can still have charged the customer. One WordPress.org case with Stripe and PayPal shows exactly that: the payment went through, but the request back to the store returned 504 and the thank-you page never loaded. If the customer tries again, you can end up charging them twice.

    WooCommerce’s troubleshooting guide for orders gives the order of checks. Open the order and read its status and notes. Search the payment gateway’s own records for the transaction. Read the gateway log under WooCommerce → Status → Logs. If the gateway shows a charge but the order is still pending, check the webhook or callback setup and match the two up before you ship anything. Only then tell the customer what to do.

    When to stop and get help

    Stop guessing once you have the URL, the time and a scope, but no logs. At that point the fix sits with whoever can see the server: your host for proxy, PHP-FPM and resource limits, or a developer for plugin code and slow queries. Send them the request, the timestamp, the duration and what you have already ruled out. If a store migration or plugin update stalls partway, don’t mark steps as complete by hand to get past the timeout. Keep the backup and get help.

    If you’d rather hand over the whole job, SiteSelf’s WordPress troubleshooting and bug fixes work starts from the error on your live site: with hosting (SSH) access it reads the logs, makes the fix, fetches the page again and tells you in chat what changed. For other errors, the guide to why WordPress is not loading sorts problems by what you see on screen.

    Frequently asked questions

    Is a 504 my host’s fault or my site’s?

    The code alone can’t tell you, and in public threads the answer goes both ways. Some 504s come from a plugin’s admin code, others from a crowded server. The logs decide it, so ask your host to match your URL and timestamp against them before you change plans or blame anyone.

    Why does the 504 still happen after I raised max_execution_time?

    Another layer is probably ending the request first, such as nginx, the host’s proxy or PHP-FPM. If the error still arrives at the same number of seconds after your change, you changed the wrong clock. Ask the host which component returned the 504.

    Why does it happen only in wp-admin?

    Admin pages skip the page cache and run plugin code that never runs for visitors. A fast cached homepage doesn’t mean the server behind it is healthy. Test with Health Check’s troubleshooting mode to find which plugin’s admin code is slow.

    Will a CDN or better hosting fix a 504?

    A CDN caches pages for anonymous visitors. It doesn’t make slow PHP faster, so admin pages and checkout still time out. Bigger hosting helps when the logs show the server is out of capacity, and does nothing for a plugin stuck in a loop.

    Will moving away from WordPress stop the timeouts?

    Not on its own. Replies in r/webdev made the point that heavy work times out on any framework if it runs inside a web request. The fix is the same anywhere: batch the work, queue it or run it from the command line.

    Is there a fix for a 500 error that hides a 504?

    Some hosts show a generic 500 page while their access log records a 504. If the 500 steps don’t help, ask what the access log recorded for that request. Our guide to fixing a server error 500 covers the real 500 cases.

  • WordPress maintenance mode plugins and when to use one

    Key takeaways

    • “Briefly unavailable for scheduled maintenance” comes from a .maintenance file that a WordPress update creates. Deleting that file takes the screen down, but the update still isn’t finished.
    • Most reports of a plugin “not working” turn out to be caching or a logged-in bypass. Purge every cache layer, then test in a private window.
    • Google Search Central recommends a 503 status with Retry-After only when a site is fully down for one or two days. For longer closures, keep the site up and turn off functions such as the cart.
    • On a store, a simple on/off plugin is enough for an update window. Builder plugins only make sense when the holding page has a marketing job.
    • WooCommerce’s update guide puts the live store in Coming Soon mode during updates and keeps checkout closed until store workflows have been tested.

    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.

    The jobWhat you needExample from the directory
    A 20-minute update windowAn on/off switch and a 503 statusSlim Maintenance Mode (10,000+ installs): no settings page, and only administrators see the site
    A branded holding page for an established businessA logo, a message and access rulesMaintenance by WebFactory (1,000,000+): a 503 status and a temporary page you edit in its settings
    A client reviewing work while the public sees a noticeA bypass by role or linkCMP by NiteoThemes (200,000+), recommended in r/Wordpress threads for its client bypass link
    A pre-launch page with a signup formA page builder and form handlingLightStart (400,000+), described on WordPress.org as a drag-and-drop page builder

    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

    How do I turn maintenance mode off?

    For a plugin, switch it off in the plugin’s settings, save, and purge every cache. For core’s update screen, delete the .maintenance file from the folder that holds wp-config.php, or run wp maintenance-mode deactivate. Then finish the interrupted update.

    Can I put WordPress in maintenance mode without a plugin?

    Not from the dashboard. Core’s only maintenance state is the temporary one it creates during updates. Developers sometimes write a small template or a server rule instead. That works, but someone has to maintain it, so most owners use a lightweight plugin.

    Does maintenance mode hurt SEO?

    A short closure with a 503 status and a Retry-After header is what Google recommends for one or two days. Problems come from long closures, a holding page served with 200 OK, or using noindex or robots.txt to hide the site. Check the status code before you leave it running.

    What’s the difference between coming soon and maintenance mode?

    Coming soon is for a site that hasn’t launched yet. Maintenance mode is a temporary outage on a site that already has visitors and search rankings. Practitioners on Reddit warn against using coming-soon mode on an established site, because it can cause indexing problems.

    Can my client preview the site while it’s hidden?

    Yes, if the plugin supports a bypass link or role-based access. Many plugins let only logged-in users through, so a client would need an account. Test the bypass with a real non-admin account before you send the link.

    Does maintenance mode protect the site during a security problem?

    No. The plugin runs inside WordPress, so an attack against PHP or the server reaches the site before the plugin loads. Use your host’s controls or a static page for that.

  • Fix WordPress permalinks that are not working

    Key takeaways

    • Click Save Changes under Settings → Permalinks without changing anything. That rebuilds WordPress’s rewrite rules, and after a migration or restore it is usually the whole fix.
    • A 404 page in your theme’s design means WordPress got the request. A bare white server error page means the server never handed the request over, so look at the server, not the dashboard.
    • Nginx never reads .htaccess. The fix there is a try_files rule in the server block, and on managed hosts like Kinsta that change goes through support.
    • Do not switch to a new permalink structure or WooCommerce product base to make 404s go away. Every existing URL changes, and old links break unless you add 301 redirects.
    • Redirect plugins cannot repair broken rewriting. Redirection’s own docs say it needs working permalinks before it can run.

    The homepage loads. wp-admin works. The editor still shows the post you published. But the link you just sent a customer returns “404 Not Found”, and so does every other post, page and product you try.

    That pattern means a routing problem, not missing content. Pretty URLs like /blue-shirt/ only work if two layers agree. WordPress needs a current set of rewrite rules, and the web server has to send each request for a path that is not a real file to WordPress’s index.php. The homepage needs no rewriting, which is why it still works. Your job is to find out which layer broke before you change anything. If the 404 is about one URL that moved, our guide to how WordPress slugs work is the better starting point.

    Which 404 are you looking at?

    Look at the error page before you touch a setting. If it shows your theme’s header, footer and styling, WordPress received the request and could not match it to content. That points at rewrite rules, the content itself or a plugin. If it is a plain white page that says “404 Not Found” with a server name like nginx at the bottom, the request never reached WordPress. That points at server configuration. WP Engine’s support docs make the same split between a WordPress-themed 404 and a default Nginx 404.

    Then check the scope:

    • Everything except the homepage fails. Rewrite rules or server routing. Keep reading.
    • One URL or a few fail. Open the item in the editor. Check that it is published, not in the trash, and that the slug matches the link. A renamed or deleted page needs a redirect, not a routing repair.
    • Only products, a custom post type or account pages fail. Probably a slug collision or a plugin. See the sections below.

    One more quick test. Find the post’s ID in the editor’s address bar (post.php?post=123) and visit yoursite.com/?p=123. If that loads while /my-post/ does not, rewriting is broken. If ?p=123 fails as well, the problem is deeper than permalinks, usually theme or plugin code changing the query.

    Re-save your permalinks first, without changing anything

    Go to Settings → Permalinks and click Save Changes. Do not pick a different option. The WordPress documentation for that screen explains that WordPress regenerates its rewrite rules there. On Apache, if WordPress can write to .htaccess, saving also updates the file.

    Test the URL that failed in a private window. If it loads, you are done. This is the standard fix after a migration, a backup restore, a change of host, or installing a plugin that adds its own URL types. Migration plugin vendors put this step at the end of their own checklists for exactly that reason.

    For custom post types, WordPress documents a longer variant: switch to the default structure, save, switch back to your real structure, and save again. It is optional. Just make sure you finish on the structure you started with.

    Developers with WP-CLI can run wp rewrite list to see whether a rule for the failing URL exists, and wp rewrite flush to rebuild the rules from the command line. Do not put flush_rewrite_rules() on every page load. WordPress’s function reference warns that flushing is expensive, and it does nothing for a server that ignores the rules.

    Why saving did not fix it

    Saving only rebuilds WordPress’s half of the routing. If the 404s are still there, check these in order. They start with the cheapest to rule out, not with whatever happens to be most common, because nobody has measured how often each cause turns up.

    A cache is still serving the old 404

    Your fix may have worked while a cache keeps handing out the old error page. Clear your caching plugin, any server cache your host runs (LiteSpeed, Varnish), and your CDN, then test logged out in a private window. WooCommerce’s product 404 documentation warns that cached 404s and testing while logged in can make a working fix look broken.

    Apache is not reading the rules

    On Apache and LiteSpeed, pretty permalinks depend on three things. WordPress’s Common Errors handbook names an inactive mod_rewrite module as a cause. Apache also ignores .htaccess completely when the directory is set to AllowOverride None. Your host controls both settings, so ask them to confirm both are on.

    The third is the file itself. It lives in the WordPress root, next to wp-admin and wp-content. Your file manager may hide it because the name starts with a dot. For a site installed at the domain root, the WordPress block looks like this:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress

    Download a copy of the file before you edit it. Many sites keep redirects and security rules in there, and pasting a fresh block over the whole file deletes them. Add or fix the WordPress block only, and keep custom rules above # BEGIN WordPress, as our guide to htaccess 301 redirects explains. Subdirectory installs need a different RewriteBase, so copy the rules WordPress shows you rather than the example above.

    If WordPress cannot write the file, the Permalinks screen tells you to update .htaccess yourself and shows the rules to paste. That usually means the file’s ownership is wrong. Setting the file to world-writable (666) is not a fix. Ask your host to correct the ownership.

    The server is Nginx, and .htaccess does nothing

    Nginx has no per-directory config files. WordPress’s Nginx handbook says WordPress cannot generate Nginx rewrite rules, so no amount of saving in the dashboard will help. Editing .htaccess on an Nginx server is the most common wasted afternoon in this whole topic. A missing .htaccess on Nginx is normal, not a fault.

    The handbook’s rule for a single site goes in the server block:

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    If a location / block already exists, edit it rather than adding a second one. Run nginx -t before reloading. On managed hosting you probably cannot touch this file. Kinsta’s docs, for example, say its WordPress sites have no .htaccess and that server configuration changes go through support. Send your host the failing URL, what you have already tried, and the exact 404 page you see.

    Two things are claiming the same URL

    The Common Errors handbook notes that a custom post type and a page with the same name cause 404s. WooCommerce’s permalinks documentation warns against using the same value for the product base and the product category base. Re-saving cannot fix a collision. Rename one of the two, save permalinks again, and add a redirect for whichever URL changed.

    A plugin or theme is intercepting the request

    Plugins that register their own content types, custom fields or URL rules can break WooCommerce account endpoints, product pages or whole sections of a site. Themes can do it too, which is when even ?p=123 URLs fail. Start with whatever was installed or updated last. Use the Health Check & Troubleshooting plugin’s Troubleshooting Mode, which turns plugins off only for your own session, or use a staging copy. Change one thing at a time, and re-save permalinks after each change. Our guide to troubleshooting plugins that are not working covers the full isolation method.

    A migration damaged the data

    If someone moved the site by running a raw SQL find-and-replace on the old domain, they may have corrupted serialized data. PHP stores the length of each string inside serialized values, and a replacement that changes the length breaks them. Practitioners report 404s, missing images and plugin errors after this kind of move. Restore from backup and redo the replacement with wp search-replace, starting with --dry-run, or use a migration plugin that handles serialized data.

    Why the 404s come back after you re-save

    If saving fixes the site for a day or a week and then the 404s return, saving is hiding the problem, not fixing it. Something keeps overwriting the rewrite rules or caching a broken state. In community threads the usual suspects are security plugins that rewrite .htaccess, host-level caching, and plugin interactions nobody pinned down. None of those threads confirmed a single root cause.

    To narrow it down, keep a copy of .htaccess from when the site works and compare it with the file the next time the site breaks. If the WordPress block has changed or disappeared, check which plugin writes to that file and look at its settings. If the file has not changed, look at caching. Do not settle for re-saving every few days on a store, where a broken return URL after payment costs you orders.

    Do not fix a 404 by changing your URLs

    Switching to “Post name” or renaming the WooCommerce product base can make the 404s go away, because WordPress rebuilds the rules along the way. It also changes every established URL. Links already shared, bookmarked and in Google’s index now point at nothing. WooCommerce’s documentation warns that old product links will return 404 unless you redirect them. Re-save the structure you have. Change it only on purpose, with a redirect map ready.

    If URLs did change, Google’s site-move guidance asks for permanent server-side redirects from each old URL to its closest new equivalent. Sending everything to the homepage instead can be treated as a soft 404. Our explainer on permanent redirects and SEO walks through the mapping. Remember that a redirect plugin cannot rescue broken rewriting: the Redirection plugin’s installation docs say it needs WordPress permalinks working first.

    When to stop and get help

    Stop clicking Save and hand the problem over when the host has to change server configuration you cannot reach, when the 404s keep coming back, when a plugin or theme conflict points into custom code, or when a migration may have corrupted the database. Several public support threads in each of these groups never reached a fix, even after the owner had tried a dozen things. Give your host or developer the failing URL, which kind of 404 page appears, whether ?p= URLs work, and what changed just before the problem started.

    If you would rather someone else does the diagnosis, SiteSelf can find and fix WordPress errors like this through chat. It needs hosting (SSH) access for server and .htaccess work, and it reports what it changed and what it checked.

    Frequently asked questions

    Where is the .htaccess file in WordPress?

    It sits in the WordPress root folder, the one that contains wp-admin, wp-includes and wp-content. Because the name starts with a dot, many file managers hide it until you turn on “show hidden files”. If your server runs Nginx, there is no .htaccess, and that is normal.

    Why does only the homepage work?

    The homepage URL needs no rewriting, so it loads even when the rewrite layer is broken. Every other pretty URL needs WordPress’s rules and the server’s routing to work together. Re-save permalinks first, then check the server.

    Should I switch to Plain permalinks to fix the 404s?

    Only as a short test. Plain URLs like ?p=123 work without rewriting, so they confirm the diagnosis, but they change every public URL on the site. Switch back and fix the rewriting rather than leaving the site on Plain.

    Why do my WooCommerce product attribute pages return 404?

    WooCommerce’s permalinks documentation says attribute archive URLs only work when archives are turned on for that attribute. Go to Products → Attributes, edit the attribute, tick “Enable archives?”, then re-save permalinks.

    Should I redirect every 404 my site reports?

    No. Redirect URLs that used to have content to the closest page that replaced them. A URL that never existed can stay a 404, and sending everything to the homepage can be treated as a soft 404.

    How do I check whether my server is Apache or Nginx?

    Look in your host’s control panel or ask support. In WordPress, Tools → Site Health → Info → Server usually lists the web server software. The bare 404 page often names the server at the bottom too.