Blog

  • What a WordPress website care plan should include

    Key takeaways

    • WordPress.org’s backup handbook says to back up files and database together, weekly for low-activity sites and daily for busy ones, and to keep 3 to 5 copies in different locations.
    • WooCommerce suggests a monthly update review for most stores, with security fixes applied sooner, plus staging, Coming soon mode and the WooCommerce database update before checkout reopens.
    • On a store, a full restore or a staging push can wipe orders placed since the copy was made. Kinsta’s docs say its database push cannot tell new WooCommerce orders from old ones.
    • Prices quoted by providers run from about 50 euros to 400 dollars a month for very different scopes, so compare the testing method, restore process and included hours rather than the price.
    • A care plan is worth most on sites that earn money or change often. On a brochure site that rarely changes, an hour of work when you need it may cost less.

    Two sites can pay for “WordPress care” and get very different service. On one, someone updates plugins on staging, checks the contact form and the checkout, and can show you a restore that worked. On the other, auto-updates run unattended, a green backup icon sits in the dashboard, and nobody opens the site afterwards. Both sites appear in a listing as “updates, backups, monitoring.”

    No one sets a standard for what a care plan has to include. You have to judge the work behind the list. This article explains what that work is, where it usually fails and what to ask before you pay. If you are comparing offers, our guide to what a maintenance package should cover goes further into contract scope.

    What does a WordPress care plan actually cover?

    A care plan is a recurring service. It nearly always covers four things: WordPress core, plugin and theme updates, backups, uptime and security monitoring, and a small amount of support time. Some plans add staging, reports, faster response or hosting. Malware cleanup, content edits, SEO and speed work are usually billed separately, so read the exclusions before the features.

    Care plans are everywhere. In The Admin Bar’s 2025 survey of 1,233 WordPress professionals, 93.1% said they offer maintenance. That is why the same three-word bullet list shows up on so many pricing pages, and why the bullet list tells you so little.

    A care plan is also not the same as managed hosting. Managed hosting looks after the server. A care plan looks after the site: the plugins, the theme, the forms, the checkout. Some hosts do part of both, so check for overlap before you pay twice.

    Why updates are where a care plan earns its fee

    Updates break sites more often than anything else on this list. One practitioner who runs automated updates across many client sites estimated on r/Wordpress that about 1 update in 20 caused a problem. That is one person’s estimate, not a measured rate, but it matches what you see in the support forums.

    The fix is also not always the obvious one. In a 2026 wordpress.org support thread, MonsterInsights reported a failed update and rolled itself back, yet the “There has been a critical error on this website” message stayed. The real cause was two Avada theme plugins that had not updated properly. Rolling back the plugin that complained did nothing. Someone had to read the error log.

    A safe update routine has the same steps everywhere:

    1. Take a full backup of files and database.
    2. Apply updates on a staging copy, in small batches, so a failure points at a short list.
    3. Check the pages that matter: forms, login, checkout, key landing pages. The homepage loading is not enough.
    4. Read the logs: wp-content/debug.log or the host’s error log.
    5. Apply the same set on the live site, then check again.
    6. Roll back only what failed.

    If you need to find a conflict on a live site, the Health Check plugin’s troubleshooting mode turns off plugins and switches to a default theme for your logged-in session only. Visitors still see the normal site. WordPress.org’s support handbook explains how troubleshooting mode works. When a plugin breaks after an update, our guide to fixing plugins that stop working covers the usual causes, including the stuck “Briefly unavailable for scheduled maintenance” message.

    Ask any provider how they handle this routine. If you would rather hand it off, the plugin updates and maintenance page explains how SiteSelf does the update cycle on request.

    WordPress care plan plugin updates pending on the Plugins screen
    Pending plugin update notices prompt administrators to review version details and test changes rather than simply clicking update on a live site. · Source: www.wpbeginner.com

    On a store, follow WooCommerce’s order

    WooCommerce’s update guide suggests reviewing updates monthly for most stores and applying security fixes sooner. It sets out a store-specific sequence:

    • Back up first.
    • Test the same set of updates on staging.
    • On staging, check product pages, cart, checkout, payments, shipping, taxes and order emails.
    • On the live site, put the store in Coming soon mode.
    • Let each update finish before starting the next.
    • Run the WooCommerce database update if WordPress prompts for it.
    • Test the store before you reopen checkout.

    The common mistakes are the reverse of that list: updating live, refreshing the page halfway through, skipping the database update, or reopening checkout before anyone places a test order.

    Why a backup that ran is not a backup that works

    A successful backup job only proves that a file was written. It does not prove you can get the site back. WordPress.org’s backup handbook sets the minimum:

    • Back up files and database together. The database holds posts, settings and orders. The files hold themes, plugins and uploads. A copy of one without the other is half a backup.
    • Back up weekly for small, low-activity sites and daily for busy ones.
    • Keep 3 to 5 recent copies in different locations, not all on the server they protect.
    • Back up the database before an upgrade.
    • Now and then, make a manual backup to check that the automated ones are working.

    Backup tools fail too. UpdraftPlus’s own changelog records fixes for jobs that failed on particular server setups, such as FTP uploads under PHP-FPM and large-file restores that ran out of PHP memory. When a backup fails, the diagnosis starts in the backup log and the server details, not with guesswork. The only real test is restoring a copy to staging and clicking through it. Our explainer on what a backup plugin covers lists the gaps to look for.

    One more catch: if the site was hacked, restoring a backup taken after the break-in can bring back the attacker’s accounts and files. Cleanup is its own job, covered in our guide to malware removal that does not come back.

    WordPress backup plugin restore screen in a care plan routine
    The prominent Restore button beside each archive serves as a reminder that a backup file offers no genuine protection until it has been deployed and verified. · Source: teamupdraft.com

    On a store, a restore can delete orders

    Restoring a full backup, or pushing a staging database to live, overwrites everything created since the copy was made. On a store, that includes orders. Kinsta’s push documentation warns that its database push cannot tell new WooCommerce orders from old ones. It offers a files-only push, a selective push that leaves out the WooCommerce tables, or syncing live to staging first. These options are specific to Kinsta, but the risk applies on any host.

    A store owner raised exactly this fear on r/woocommerce. The replies gave the practical rule: treat code rollback and database restore as separate operations. Ask a provider how they roll back an update without touching orders. A vague answer tells you something.

    Why “the site is up” misses the failures that cost money

    Uptime monitoring checks that the server answers. A site can answer perfectly while it loses money. Practitioners in a 2026 r/Wordpress thread listed the failures that slipped past their monitoring:

    • Contact forms stopped sending because the SMTP login expired.
    • Checkout failed only in Safari because of a JavaScript error.
    • An SEO plugin change added noindex to pages that should rank.
    • Caching problems went unnoticed until clients reported them.

    The fix is to test the site the way a stranger uses it, not as a logged-in admin. After changes, submit a real form, place a test order, open the browser console, and check that key pages are not set to noindex. Admin sessions skip caches and hide permission problems, so a logged-in admin sees a healthier site than visitors do.

    What a care plan costs, and why prices don’t compare

    Prices quoted by providers in Reddit threads run from about 50 euros a month for bare version updates to 375 or 400 dollars a month for larger packages. Those numbers cover very different work, so an average means nothing. One r/woocommerce commenter put the small end plainly: a 40 to 50 dollar retainer buys less than an hour of work. In The Admin Bar’s survey, the average hourly rate was $96.36 and the median $95.

    The condition of the site matters more than the plan tier. Sites with 20 or 30 plugins, an old theme or a build inherited from someone else take far more time. One freelancer described spending 5 to 10 hours a week on maintenance. Another described about an hour a month overseeing 60-plus well-kept sites. Deleting plugins you no longer use is the cheapest maintenance there is.

    Owners mostly complain about not seeing the work. A widely discussed r/smallbusiness post described an owner paying $400 a month whose site still had pending updates and unused plugins. Whatever the plan, ask for a record of what was done each month.

    When is a care plan worth paying for?

    It depends on what a broken afternoon costs you. A plan is worth the most when:

    • the site takes orders, bookings or leads;
    • it changes often;
    • nobody in-house can read an error log.

    A brochure site that changes twice a year is a different case. Its owner may do better with Site Health (Tools, then Site Health), a reliable host backup, and paying for an hour of work when something comes up. The tradeoff is real, though: without someone who already knows the site, each problem means finding help from scratch.

    WordPress Site Health screen used as a free care plan check
    The Site Health tool separates urgent vulnerabilities from recommended improvements to help site owners prioritize essential fixes. · Source: aioseo.com

    What to ask before you sign

    • Are updates tested on staging first, or applied directly to the live site?
    • What gets checked after an update: the homepage, or forms and checkout too?
    • Where are backups stored, how many are kept, and when was a restore last tested?
    • On a store, how does a rollback avoid wiping new orders?
    • Is fixing a broken update included, or billed as extra work?
    • Is malware cleanup included, or only scanning?
    • How many hours of small changes are included, and what is the rate after that?
    • What report do I get each month?
    • If I cancel, who holds the backups, licences and admin access?

    How the work changes when an agent does it

    Most maintenance work is small. The process around it often isn’t: a ticket, a wait, someone who has to learn the site again, and a “done” email with no detail. SiteSelf is an AI agent for existing WordPress sites. You tell it what needs doing in chat, it does the work on the live site, and it reports what changed and what it checked.

    Example request: “Update the plugins on our site. Do WooCommerce last, tell me if anything needs the database update, and check the contact page and checkout afterwards.”

    The agent lists the pending updates. Before each change, it says what is about to change and whether it can be undone. It applies the updates, runs the WooCommerce database update if one is needed, then fetches the changed pages and reports back in plain language. The work is recorded, so next month you can see what happened this month.

    Access depends on the task. The SiteSelf Connector plugin from the WordPress.org directory covers content and settings work. Reading debug.log, removing a stuck .maintenance file or other file and code work needs hosting (SSH) access.

    The limits are part of the answer. The check is a fetch of the changed page and a written report. It is not a screenshot or a test on every device, so a Safari-only checkout bug can still get through, and a real test order is still your job. Nothing is scheduled and nothing runs unattended, so SiteSelf does not monitor the site between requests. It also does not confirm your backups. Check that a recent restore point exists before a big update cycle. Pages built with Elementor, Divi or Beaver Builder are refused at the moment of work, with the reason. The update and maintenance page shows the rest, and pricing is credit-based.

    Frequently asked questions

    How often should a care plan update my site?

    No single schedule fits every site. WooCommerce suggests a monthly update review for most stores and applying security fixes sooner. For backups, WordPress.org suggests weekly on quiet sites, daily on busy ones, and always before an upgrade.

    Is a care plan the same as managed WordPress hosting?

    No. Managed hosting looks after the server, and some hosts add backups and automatic updates. A care plan covers hands-on work on the site: updates, troubleshooting and checks after changes. Compare the two lists so you do not pay for the same backups twice.

    Does a care plan include content edits?

    Usually only within a capped allowance of time each month. Past that, providers bill hourly or quote the work as a separate project. Ask for the cap and the rate in writing.

    Can I maintain a WordPress site myself?

    Yes. WordPress.org’s backup handbook, the Site Health screen, the Health Check plugin and WooCommerce’s update guide cover the steps. The cost is time, plus the risk of debugging alone when an update breaks something.

    What should a monthly care report show?

    Which updates were applied and which were held back, the date of the last backup and last restore test, what was checked after changes, and any open issues. A report that only says “all good” proves nothing.

    Can I trust auto-updates on their own?

    On a simple site with a recent backup, mostly yes. On a store or a site with many plugins, auto-updates still need someone to check forms and checkout afterwards, because a site can load fine while a key feature is broken.

  • How to determine your WordPress version

    Key takeaways

    • Tools → Site Health → Info → WordPress shows the version in use. If the screen is missing, the site is older than WordPress 5.2 or your account isn’t an administrator.
    • On the server, wp core version and the $wp_version line in wp-includes/version.php are the direct answers. Don’t confuse $wp_version with $wp_db_version, which is a database revision.
    • SmartWP scanned the 20,000 most-visited domains in September 2026 and found that 38% of the WordPress sites hid their version. A missing generator tag means ‘unknown’, not ‘up to date’.
    • WordPress uses its own core version in a ?ver= string only when the asset doesn’t set a version. Plugin and theme files carry their own numbers, which is how scanners end up reporting the wrong version.
    • Hiding the version doesn’t replace updating. W3Techs counted 7% of detected WordPress sites on version 5 or older on Oct. 10, 2026.

    You check your WordPress version and get one number. A security scanner reports a second one, and a CSS file’s URL seems to show a third. They can’t all be right. One of them comes from the installation itself, and the others are signals that the installation, a plugin or a cache happens to send out.

    Determining the version is mostly about knowing which kind of answer you have. If you just need the quickest place to look, our short guide to checking the WordPress version covers that. This article covers the next step: which source to trust, how to read it from the server, and what to do when two sources disagree.

    Which checks give you the real answer?

    Checks that read the installation give the real answer. Checks that read the public website only give clues. The table ranks them by how directly they read the installed files.

    MethodAccess neededWhat the result means
    wp core versionSSH with WP-CLIThe installed version, read from the files on the server
    wp-includes/version.phpSSH, FTP or the host’s file managerThe installed version, if you open the right installation
    Site Health → InfoWordPress administratorThe version WordPress reports for itself
    At a Glance, Updates, admin footerLogged-in userFast everyday checks, same source
    Generator meta tag, feed, ?ver=, readme.htmlNoneA clue that may be missing, cached or misleading

    Base any decision on one of the first four rows: whether to update, whether a plugin will work, whether a scanner is right. The last row is fine for a quick look at a site you don’t control. It shouldn’t settle anything.

    How to find the version in the WordPress dashboard

    If you can log in as an administrator, open Site Health. WordPress.org’s documentation puts it under Tools → Site Health → Info, and the WordPress section of that tab lists the version.

    1. In the admin menu, go to Tools → Site Health.
    2. Open the Info tab.
    3. Expand the WordPress section and read Version.

    If the menu doesn’t show Site Health, one of two things is going on. WordPress.org’s support page says the feature arrived in WordPress 5.2, so the site may be older than that. Or your account doesn’t have administrator rights. On a site that old, finding the version is the smaller problem.

    The version also shows in a few faster places: the At a Glance box on the dashboard home, Dashboard → Updates, and the bottom-right corner of most admin screens. On a WooCommerce store, go to WooCommerce → Status and look under WordPress environment. That system status report is also what WooCommerce support usually asks for.

    Site Health is also a useful first stop on a site you’ve just inherited. One screen shows the WordPress, PHP, theme, plugin and server details before you touch anything.

    How to read the version from the server

    Server access gives you the answer with no dashboard, cache or security plugin in between. That matters when you can’t log in, when the dashboard is broken, or when you need a result you can paste into a ticket.

    With WP-CLI

    WP-CLI’s documentation describes wp core version simply as the command that “displays the WordPress version.” Run it from the WordPress root folder, or point it at the folder:

    wp core version
    wp core version --path=/var/www/example.com/public_html
    wp core version --extra

    --extra adds more detail, including the database revision that the core files expect. On a multisite network, every site runs the same core version, so checking any one of them answers for the whole network.

    If WP-CLI replies “Error: This does not seem to be a WordPress install. Pass –path=path/to/wordpress or run wp core download.”, it usually isn’t broken. Liquid Web’s troubleshooting guide puts that message down to running the command from the wrong directory. Add --path. If the path is correct and the error stays, check the folder permissions for the user you’re logged in as.

    From wp-includes/version.php

    The release number lives in one line of wp-includes/version.php. In a terminal:

    cd /path/to/wordpress
    grep '^\$wp_version' wp-includes/version.php

    Without a terminal, open the file in your host’s file manager or over FTP and find the line that starts with $wp_version =. Two warnings apply. First, read the file and leave it alone. Editing the number changes nothing about the code and makes every later check wrong. Second, the same file also holds $wp_db_version. That is a database schema revision, a different and much longer number. It is not the release you’re looking for.

    Servers that host several sites, or keep staging next to production, are where people read the wrong wp-includes folder. Before you trust the number, confirm that the folder is the one serving the domain you care about.

    Checking that the files are what the number claims

    A version number tells you what the installation says it is. It doesn’t tell you whether someone changed the files. wp core verify-checksums compares the core files against WordPress.org’s published checksums. A mismatch can come from a half-finished update or a local edit as easily as from an attack, so look into it before you replace anything.

    What a public check can and cannot tell you

    Without a login, you can only collect clues. Try them in this order and treat every result as provisional.

    1. Page source. View the source of the home page and search for “generator”. WordPress core prints a line like <meta name="generator" content="WordPress x.y.z"> through wp_generator() on the wp_head hook.
    2. The feed. Open /feed/ and look for a generator line such as wordpress.org/?v=x.y.z. The feed comes from a separate function, the_generator(), so it can still show the version after the HTML tag is gone.
    3. Asset URLs under /wp-includes/. WordPress’s wp_enqueue_style() reference says that when an asset is registered without its own version, WordPress adds the installed core version as the ?ver= value. Core files under /wp-includes/ are the most likely to show it. Files from plugins and themes carry their own versions.
    4. /readme.html. Sources disagree on whether current installs still show a version in this file. Hardened sites often delete or block it, and a 404 or 403 tells you nothing.
    WordPress generator meta tag showing the version in page source
    A page source inspection reveals the default generator meta tag broadcasting the exact WordPress version to anyone who checks. · Source: www.youtube.com

    Expect to come up empty fairly often. SmartWP scanned the 20,000 most-visited domains in September 2026 and reports that 38% of the WordPress sites it found hid their version. Paths like /wp-content/ can confirm a site runs WordPress, but they don’t reveal the version. An honest result is often “WordPress, version unknown”. That doesn’t mean the site is current, and it doesn’t mean the site isn’t WordPress.

    Why two tools report different versions

    They’re usually measuring different things. Work through these in order, because the early ones explain most cases.

    1. Check from inside first. Use Site Health or wp core version to see what the installation says.
    2. Confirm the installation. Make sure you’re on the right site, path, domain, and production rather than staging.
    3. Clear every cache. WordPress.org’s Updating WordPress page notes that a cache can keep showing the old version after an update. Clear the caching plugin, the host’s cache and any CDN, then look again.
    4. Finish the update. If WordPress shows a database update prompt, run it. If the site is stuck in maintenance mode after a failed update, the same page says to delete the .maintenance file over FTP.
    5. Question the scanner. A scanner that reads a version from a bundled library or a plugin’s ?ver= string can report an old WordPress version on a site that has been updated. If your files and WP-CLI agree with each other, read the scanner’s evidence before you replace anything.

    Don’t fix a disagreement by copying core files over the site. Find out which number is wrong first, and keep both results with their sources until you know.

    Should you hide the version once you know it?

    You can, but it’s a minor step and it doesn’t make an old site safe. WordPress’s Hardening handbook puts keeping WordPress updated first and treats security through obscurity as unsound when it’s the main defence. It doesn’t help SEO either: Google’s list of the meta tags it supports doesn’t include generator.

    If you do hide it, cover more than the obvious tag:

    • remove_action( 'wp_head', 'wp_generator' ); removes only the tag in the page head.
    • The feed’s generator line is separate output, so it needs its own handling.
    • Plugins and page builders can print their own generator tags.
    • Stripping every ?ver= string breaks cache-busting, and visitors may then get old CSS and JavaScript after you deploy a change.

    Plugins exist for this. Check their status before you install one. The WordPress.org listing for Meta Generator and Version Info Remover covers the head tag, RSS feeds and asset versions, but it also warns that the plugin hasn’t been tested with the latest three major WordPress releases. Server rules can reduce what the site reveals too. Our article on Apache security for WordPress covers blocking files like readme.html.

    What to do with the number

    Compare it with the current release. If you’re behind, plan an update: take a backup you know how to restore, test on staging if the site makes money, and never delete wp-content during a manual update. Old versions are still common. W3Techs counted 4.8% of detected WordPress sites on version 5, 2.0% on version 4 and 0.2% on version 3 on Oct. 10, 2026. Those figures come only from sites that reveal their version, so the real share may be different.

    If you’d rather not run the update yourself, “update WordPress and tell me what changed” is the kind of request SiteSelf takes on through chat. Its page on keeping WordPress up to date explains how that work is handled.

    If you look after many sites, checking them one by one in the dashboard doesn’t scale. Add the version check to onboarding and to whatever tool you already use to manage multiple WordPress websites.

    Frequently asked questions

    Can I find the WordPress version of a site I don’t own?

    Only through public clues: the generator tag, the feed, core asset URLs and readme.html. Detection tools read the same signals, so when a site hides them, the tools hit the same wall. Report the result as a clue, or as “unknown”.

    Does a missing generator tag mean the site isn’t WordPress?

    No. Removing it is a common hardening step, and many security plugins and hosts do it. Paths such as /wp-content/ and /wp-includes/ in the page source are better evidence that a site runs WordPress.

    Is the ?ver= number on a stylesheet the WordPress version?

    Sometimes. WordPress adds the core version only when the asset doesn’t set its own, which mostly means core files under /wp-includes/. A number on a plugin or theme file is that plugin’s or theme’s version.

    How do I get the version in PHP code?

    Community answers suggest get_bloginfo( 'version' ), which returns the release string from inside WordPress. Use it in admin-only output, not on public pages, unless you’re happy to show the version to anyone who looks.

    What about sites hosted on WordPress.com?

    WordPress.com Support says plugin-enabled sites show the version in the Hosting Dashboard, under the site title and address. Other WordPress.com sites always run the latest version, so there’s nothing to check.

    I updated but the dashboard still shows the old version. Did it fail?

    Usually not. Clear the plugin, host and CDN caches and check again. If the site is stuck in maintenance mode, delete .maintenance over FTP. If WP-CLI still reports the old version after that, the update didn’t finish, and the Updating WordPress guide covers a manual retry.

  • How to add a gallery lightbox in WordPress

    Key takeaways

    • WordPress 6.4, released November 7, 2023, added Enlarge on click to the Image and Gallery blocks. Guides that say you need a plugin for this are out of date.
    • Core blocks, the legacy shortcode, WooCommerce product galleries and builder galleries each keep their lightbox setting in a different place. Changing one does nothing to the others.
    • The most common failure is two lightboxes handling the same click. Turn one off. Adding a third plugin or hiding one with CSS makes it worse.
    • If the Console shows ‘jQuery is not defined’, JavaScript optimisation is running the lightbox script too early. Exclude that one file instead of switching optimisation off for the whole site.
    • A finished lightbox opens on a real phone, closes with Escape, keeps keyboard focus inside the overlay and sends focus back to the thumbnail when it closes.

    Since WordPress 6.4, released on November 7, 2023, the Image and Gallery blocks can open a clicked image in an overlay without any plugin. Many tutorials still say you need one. Whether you actually do depends on which gallery system the page uses. A WordPress site can have four of them, and each one’s settings leave the others alone.

    So start by finding out what the page is really running. Then turn on the right setting. If the lightbox still misbehaves, work through the causes below in order.

    Which gallery system is your page actually using?

    Open the page in the editor and click the gallery. The block name or widget name tells you which system owns it. If you see a shortcode or a plugin’s own panel, it isn’t a core gallery.

    What you findWhat it isWhere the lightbox setting lives
    A block named Gallery or ImageCore WordPress blockThe block’s link options: Enlarge on click
    in a Shortcode block or the Classic editorLegacy shortcode galleryNone in core. You need a plugin that supports it
    Images on a single product pageWooCommerce product galleryThe Product Gallery block, or your theme for classic product pages
    A widget in Elementor, Kadence or a similar toolTheme or page builder galleryThe widget’s own settings
    A panel from FooGallery, NextGEN, Envira, Modula and so onGallery pluginThat plugin’s settings screen

    To check what visitors get, right-click a gallery image on the live page and choose Inspect. Core galleries carry the class wp-block-gallery. Plugin and builder galleries usually include the plugin’s name in their class names.

    How to turn on the built-in lightbox for a Gallery block

    You need WordPress 6.4 or later and permission to edit the page. If you’re not sure which version you run, check your WordPress version first. On older versions the option doesn’t exist.

    1. Open the page in the block editor and select the whole Gallery block, not one image inside it. If you keep landing on a single image, open List View and click the Gallery row.
    2. Click the link icon in the block toolbar and choose Enlarge on click. Some sources call it Expand on click, so use whatever label your version shows.
    3. For a single image, select the Image block, open Link and choose the same option.
    4. Save or update the page.
    5. Open the live page in a private window and click a thumbnail.
    WordPress Gallery block link menu with Enlarge on click selected for the gallery lightbox
    Selecting Enlarge on click within the Gallery block toolbar enables the native lightbox effect across all included images. · Source: twentig.com

    Here is what should happen. The image grows into an overlay on the same page, the URL stays the same, and a close button or the Escape key brings you back. If the image opens as a bare file in a new tab, the gallery is set to link to the media file. If you land on a page with one image on it, it’s linking to the attachment page.

    Previous and next arrows depend on your version. WordPress.org’s current Gallery block documentation describes moving between images in the lightbox. Earlier versions opened each image on its own: in March 2025 a Reddit reply pointed out that Enlarge on click alone did not give you a sliding gallery. If you don’t see arrows, update WordPress before you install anything.

    When a gallery plugin earns its place

    Core handles click to enlarge. A dedicated plugin makes sense when you need things core doesn’t do:

    • masonry, justified or filterable layouts;
    • pagination for hundreds of images;
    • video in the same gallery;
    • albums;
    • control over how captions look.

    One small-business owner on Reddit with 350 tagged images is a fair example of a plugin-sized job. A portfolio with twelve photos isn’t.

    A plugin also adds costs. It’s one more lightbox that can clash with core or your theme. Many advanced features sit in paid tiers. And it has to keep up with WordPress. After WordPress 6.7, WP Featherlight kept working on existing galleries, but the option to enable it on new ones disappeared. The site owner estimated that posting would now take two to three times as long.

    If you do add one, read its setup notes for the link setting it expects. Many plugins need images to link to the media file and won’t fire on Enlarge on click or None. Turn the core lightbox off on any gallery the plugin handles. Our guide to installing a WordPress plugin safely covers how to add one without surprises.

    WooCommerce product galleries follow their own rules

    Changing a Gallery block in a post or page does nothing to your product pages. WooCommerce runs its own gallery, and the setting depends on your theme.

    • Block themes: edit the Single Product template and select the Product Gallery block. WooCommerce’s documentation says it supports zoom, a full-screen pop-up and previous/next navigation. The pop-up is a block setting called Open pop-up when clicked.
    • Classic themes: WooCommerce says the full-screen view behind the magnifying-glass icon depends on theme support. If your theme doesn’t declare it, you won’t get it. Changing that takes theme code or a theme with the support built in.

    One more WooCommerce detail: the main Product Image already shows first in the gallery. If you add it again under Add product gallery images, it appears twice.

    Why the lightbox does not open, opens twice or fails on mobile

    Nobody publishes numbers on how often each cause turns up. Across support threads, though, the pattern is consistent: competing scripts come first, optimisation second, and settings and markup after that. Change one thing at a time and retest after each change.

    Two lightboxes are handling the same click

    The symptoms are an overlay inside an overlay, two sets of arrows, a close button you have to click twice, or a page that stops scrolling. This happens when a theme, a builder, core and a plugin all respond to the same click. The Responsive Lightbox documentation lists a theme’s own lightbox as a common cause of two lightboxes opening at once.

    Turn one of them off. In one Reddit thread, a site owner ran Meow Lightbox alongside the core lightbox and tried to fix the clash with CSS and JavaScript. Images vanished and the page stopped scrolling. Hiding a lightbox with CSS doesn’t stop its script from running.

    Script optimisation ran the lightbox too early

    Open your browser’s developer tools and check the Console tab. If you see “jQuery is not defined”, a script is running before jQuery has loaded. Defer, delay, combine and minify settings in caching plugins often cause this.

    Browser Console showing jQuery is not defined, a common cause of a broken WordPress gallery lightbox
    The browser console displays an Uncaught ReferenceError when dependent scripts attempt to execute before jQuery has loaded into memory. · Source: kinsta.com

    In a July 2026 FooGallery support thread, turning off Autoptimize’s JavaScript optimisation fixed the gallery. Excluding foogallery.min.js from optimisation kept it working with optimisation back on. LiteSpeed documents the same approach:

    1. Load the page with /?LSCWP_CTRL=before_optm to see it unoptimised.
    2. Turn off CSS and JS optimisation and purge everything.
    3. Test JavaScript and CSS separately.
    4. Exclude one file at a time, purging between tests.

    Don’t leave optimisation off for the whole site. A single exclusion fixes the gallery and costs far less speed.

    The link setting is wrong for the lightbox you use

    When the link setting is wrong, you get no error at all. The image does nothing, opens in a new tab or goes to an attachment page. Core needs Enlarge on click. Most plugins need Media file. Neither works with None.

    The legacy shortcode is its own case. A WordPress.org support thread from 2026 confirms that isn’t supported. Convert the gallery to a Gallery block or use a plugin that supports the shortcode.

    The lightbox cannot attach to the gallery’s markup

    Many lightbox plugins only recognise standard WordPress gallery markup. Responsive Lightbox’s documentation says native galleries work but galleries built by themes or other plugins may not. Galleries that load images after the page loads, through AJAX or infinite scroll, cause the same problem. The lightbox scans the page once, before those images exist.

    Look for a compatibility setting before you write code. Responsive Lightbox has an option to trigger ajaxComplete under Custom Events, and Jetpack galleries have a Force gallery lightbox option. “Each plugin works on its own” doesn’t tell you they work together.

    A cache is still serving the old page

    If your fix works while you’re logged in but visitors still see the broken version, a cache is serving them a stored copy. Purge the caching plugin, then the host’s server cache, then the CDN, and retest in a private window. Kinsta’s documentation says clearing the server cache doesn’t clear the CDN, which can keep old JavaScript, CSS and images.

    It fails only on phones

    Test on the device that fails, not a resized desktop browser. Mobile failures tend to be specific to one setup:

    • A NextGEN and Enfold site showed “Gallery could not load” on iOS until a CSS height fix for that theme.
    • A FooGallery page with more than 240 images crashed on iPhone. Support suggested setting the lightbox scroll bar option to Default, using two columns on mobile and adding pagination.

    Very long galleries are the common thread. Split or paginate them.

    Isolate it when none of the above is obvious

    The Health Check plugin’s troubleshooting mode disables plugins and switches to a default theme for your logged-in session only. Visitors see nothing change. Turn plugins back on one at a time until the lightbox breaks. Our guide to fixing plugins that stop working walks through the same method in more detail.

    Stop and get help when the Console shows an error inside the gallery plugin’s own file, when the gallery works in the editor but not on the live page, or when the fix means editing PHP. Send the plugin’s support forum your plugin and theme names and versions, your WordPress and PHP versions, and the full error text. If you’d rather not trace it yourself, SiteSelf can find and fix the broken feature on your live site and report what it changed. Script exclusions and code changes need hosting access.

    Check keyboard and search behaviour before you call it done

    A lightbox is a modal dialog, and the W3C’s ARIA Authoring Practices Guide describes how one should behave:

    • Focus moves into the overlay when it opens.
    • Tab and Shift+Tab stay inside it.
    • Escape closes it.
    • Focus goes back to the thumbnail that opened it.
    • The page behind can’t be used while it’s open.
    • A visible close button is part of the same pattern.

    Test it with only the keyboard. Many lightboxes look fine and still trap keyboard users.

    Give every gallery image real alt text. Use alt="" only for images that are purely decorative. For search, Google’s lazy-loading guidance says content has to load when it becomes visible, without anyone clicking. A lightbox that shows a larger version is fine, as long as the thumbnail is a real image on the page and not something only a click reveals.

    Frequently asked questions

    Is a gallery lightbox the same as a lightbox popup?

    No. In marketing tools, a “lightbox” is usually a newsletter or offer popup that covers the page. A gallery lightbox opens a larger image when someone clicks one. Different tools handle each, so search for the one you mean.

    Do I need to pay for a lightbox?

    Not for click to enlarge. Core does it for free on Image and Gallery blocks, and the main gallery plugins have free versions. Paid tiers usually unlock layouts, video, albums and selling features. Most are billed yearly.

    Does the core lightbox work with the Classic editor?

    No. Enlarge on click is a block setting. Galleries made with the Classic editor or the shortcode need a plugin that supports them, or need converting to a Gallery block.

    Why does the lightbox work in the editor but not on the live page?

    The editor loads scripts differently and skips your page cache and optimisation. First rule out cache and optimisation using the steps above. In a 2024 Essential Addons for Elementor thread, neither was the cause. It was a plugin bug, fixed in a development build from the vendor.

    Why did my lightbox break after a WordPress update?

    Updates can change how block markup or core’s own lightbox behaves, and older plugins may not keep up. Check whether the plugin has been updated recently and read its changelog. A changelog entry is a lead, not proof. Confirm the cause by isolating plugins as described above.

    Can a lightbox show video?

    The core lightbox handles images. Several gallery plugins support video in the same gallery, so check that feature before you choose one. Embeds from third-party services sometimes refuse to open in any lightbox.

  • How to start a blog on WordPress without overbuilding it

    Key takeaways

    • WordPress.org is free software you install on hosting you pay for. WordPress.com is a hosted service with a free plan on a wordpress.com subdomain. A WordPress.org account does not give you a site.
    • Choose Post name permalinks before you publish much. WordPress says permalinks are meant to be permanent, and changing them later sends old links to 404 unless you add redirects.
    • The Posts page is a list that WordPress builds and your theme displays, so the page’s own content and template can be ignored. Change its look in the theme’s blog settings.
    • Checking that a post displays is not the same as checking that Google can index it. Make sure ‘Discourage search engines’ is off, check your SEO plugin’s per-post-type setting, then run URL Inspection in Search Console.
    • When something breaks, deactivate plugins and turn them back on one at a time, then try a default theme. Fewer plugins means fewer suspects.

    One small business owner on r/smallbusiness said they had spent “around $500 without visible progress” on a WordPress site and were still working through tutorials and templates. That is the usual way a first blog fails. WordPress was not too hard for them. They kept adding layers before the site had published anything.

    The setup itself is short. You choose a kind of WordPress, publish a post, decide where posts appear, set the URL structure, and check that search engines are allowed in. Each step is below, followed by what usually breaks and how to tell when the problem is no longer a settings problem. If you are building pages around the blog, our guide to adding pages in WordPress covers that side.

    Which WordPress do you actually need?

    Decide this first, because the two products work differently. WordPress.org’s own documentation describes WordPress as free, open-source software that you install on hosting you choose. WordPress.com is a hosted blogging service run by Automattic. People mix them up all the time. In a 2025 WordPress.org support thread, the poster expected their WordPress.org account to come with a site and a dashboard. It doesn’t. That account is only for the forums and community.

    • WordPress.com fits if you mainly want to write. Hosting, updates and SSL are handled for you. The Free plan puts you on a wordpress.com subdomain with no custom domain.
    • Self-hosted WordPress fits if you want full control over themes, plugins and code. You pay for hosting and usually a domain, and you are responsible for updates, backups and security, or you pay a managed host to handle them.

    Neither choice is permanent. You can move a WordPress site later. For a business, the blog should usually live on the company’s existing domain. Practitioners on r/marketing give the reason: links and search visibility build up on one domain instead of being split across two.

    What does it cost to start a WordPress blog?

    It can cost nothing, or several hundred dollars in the first year. Published figures vary because each source counts different things. WordPress.com Free costs $0. When we checked its pricing page, the Personal plan was $9 a month billed monthly or $4 a month billed annually. Annual plans include a custom domain for the first year and monthly plans do not. WordPress.com’s own cost article says a .com domain usually costs $13 to $25 a year after the first year.

    For self-hosted sites, cheap shared hosting with an auto-installer is enough for a blog if you are willing to learn by fixing your own mistakes. Managed hosting costs more and takes care of backups and updates. Introductory prices are low, and renewal prices are usually higher and harder to find. Before you choose a cheap host, check whether backups and support are included or sold as extras.

    How to set up the blog, step by step

    You need administrator access to the dashboard. Every step below happens there, and none of it needs code.

    1. Publish one real post. Go to Posts → Add New, write it, and click Publish. In the block editor you then confirm with a second Publish button. Save draft does not publish the post. Your posts page stays empty, or can even return a 404, until at least one post is published.
    2. Decide where posts appear. Open Settings → Reading. “Your latest posts” puts the post list on the homepage. “A static page” lets you pick one page as the homepage and a different page, often an empty one called “Blog”, as the Posts page. One page cannot do both jobs. Our guide to editing your WordPress homepage explains why only published pages appear in that dropdown.
    3. Set permalinks once. Go to Settings → Permalinks, choose Post name and save. WordPress.org’s permalink documentation says these URLs are meant to be permanent. If you change the structure on a site that already has traffic, old links return 404 unless you add redirects.
    4. Let search engines in. In Settings → Reading, untick “Discourage search engines from indexing this site”. WordPress’s Reading settings documentation says this option adds a noindex,nofollow directive to the whole site. Many people tick it while building and forget to untick it.
    5. Add only the plugins you have a reason for. A backup plugin and one SEO plugin cover most new blogs. If you use a caching plugin, install only one. Popular plugins have millions of installs, but that only tells you a plugin is popular, not that you need it. Our walkthrough on installing a WordPress plugin safely covers the steps.
    6. Check the post the way Google sees it. Add the site to Google Search Console, paste the post’s URL into URL Inspection, and read the result.

    When you are done, the post loads at a clean URL like yoursite.com/first-post/, it appears on the homepage or Blog page, and URL Inspection reports no noindex. Leave the theme alone until you have published a few posts. Pick a free theme that already looks close to what you want and get on with writing.

    Why the blog page ignores the design you gave it

    The Posts page is not a normal page. WordPress builds the list of posts, and your theme decides how that list looks. WordPress.org’s Reading settings documentation says the page’s own content and assigned template may be ignored. If you designed that page in a page builder, your layout will not appear and the page will look different from the one you built.

    A 2025 WordPress.org support thread called “Adding a blog” was solved this way: the user set the page as the Posts page in Settings → Reading, then changed the look in the theme’s blog or archive settings. In a block theme, that means editing the blog template in the Site Editor, not editing the page.

    WordPress Site Editor showing the blog template that controls the posts page layout
    Inside the WordPress Site Editor, the theme template governs the query loop layout rather than any content designed on the static page. · Source: fullsiteediting.com

    Why a published post is not showing in Google

    Whether a post displays, whether Google finds it, and whether Google indexes it are three separate questions. A post can look perfect and still not be indexable. Check these in order:

    • Site-wide noindex: the “Discourage search engines” box is still ticked.
    • SEO plugin settings: Yoast and similar plugins can set a whole post type to noindex. Yoast’s help on common XML sitemap errors says a post is left out of its sitemap if it is noindexed, if its canonical URL points somewhere else, or, for the News sitemap only, if it was published more than 48 hours ago.
    • robots.txt used instead of noindex: Google’s documentation on blocking indexing with noindex explains that if robots.txt blocks a page, Google cannot read the page’s noindex. Use noindex to keep a page out of search.

    Even with everything set correctly, Google’s sitemap overview says a sitemap helps Google find pages but does not guarantee they will be indexed. A recrawl request is also only a request. New sites get indexed slowly, and they get traffic even more slowly. For titles, descriptions and sitemaps in more depth, see how to do SEO on WordPress.

    What breaks first on a new blog, and the first fix

    The order below is based on how often each problem comes up in support forums and documentation. Nobody has measured it. Each problem shows a message you can recognise.

    “There has been a critical error on this website”

    The usual cause is a plugin or theme conflict, often right after you added several things at once. WordPress emails the admin address with details, and if debugging is turned on, wp-content/debug.log names the file involved. WordPress.com’s guide to finding a plugin or theme conflict describes the method: deactivate every plugin, turn them back on one at a time, and switch to a default theme if the error remains. Take a backup first. Our guide to fixing plugins that are not working goes through each step.

    WordPress critical error on this website message on a new blog
    The standard WordPress critical error screen indicates that an incompatible plugin or theme has caused a fatal conflict on the site. · Source: www.wpbeginner.com

    “Not secure” or a certificate error after connecting a domain

    This is almost always a DNS problem, not a theme problem. Point the domain’s DNS at your host first, then wait for the SSL certificate. WordPress.com says certificates usually arrive within minutes but can take up to 24 hours. A CAA DNS record can also stop Let’s Encrypt from issuing a certificate.

    “Error establishing a database connection”

    The WordPress Advanced Administration Handbook lists three causes: wrong database credentials in wp-config.php, a database server that is down, or a host limit you have hit. Check the database name, user, password and host against what your host gave you. If they match, contact the host and don’t guess.

    The homepage works but every post returns 404

    The rewrite rules are stale. Open Settings → Permalinks and click Save Changes without changing anything. If posts still 404, the server may not have Apache’s mod_rewrite enabled, which your host has to fix.

    “Publishing failed” or “not a valid JSON response”

    Copy your text somewhere safe first. Then try another browser, turn off browser extensions, and look for a plugin conflict. WordPress.com’s support pages connect the “not allowed to assign the provided terms” version of this error to duplicate tags or categories.

    When to stop and get help

    Stop changing settings when the fix needs server access you don’t have: a database error after you have confirmed the credentials, mod_rewrite, or DNS records at a registrar you can’t log into. Those belong to your host. Stop too if you have spent a week on themes and still have no posts. In a 2019 r/Wordpress thread, one person reported about 120 active hours on a basic blog. Most of that time goes into design work that one published post would make unnecessary.

    If you would rather describe the work than do it, SiteSelf for publishers drafts, updates and publishes posts on an existing WordPress site through chat, then checks the live page and reports what changed.

    Frequently asked questions

    Can I start a WordPress blog for free?

    Yes, on WordPress.com’s Free plan, which includes hosting on a wordpress.com subdomain. You cannot connect a custom domain on that plan. Self-hosted WordPress is free software, but you have to pay for hosting and usually a domain.

    Do I need to know how to code?

    No. Publishing, Reading settings, permalinks and plugins are all handled in the dashboard. You only get near code with server problems like database credentials or rewrite rules, and your host can usually fix those.

    Do I need a premium theme?

    No. A free, well-maintained theme with good mobile layout is enough for a blog. Spend money where something specific is missing, not on a theme demo you will have to strip back.

    I run a WooCommerce store. Where does the blog go?

    Set the blog under Settings → Reading → Posts page and the shop under WooCommerce → Settings → Products → Shop page. Use a different page for each. If both point to the same page, one of them stops working.

    Does speed matter for a new blog?

    Yes, and plugins are where most of the weight comes from. HTTP Archive’s 2024 Web Almanac found that 40% of WordPress sites passed all three Core Web Vitals on mobile, up from 28% the year before. A lean theme and few plugins give you a better start.

    How long until the blog gets traffic?

    Nobody can give you a reliable timeline, and anyone who promises one is guessing. New sites do better writing about narrow, specific searches than broad ones. Publishing regularly and sharing posts outside search matters more than any setting in this guide.

  • Do you need a WordPress plugin for a landing page?

    Key takeaways

    • Start with what the site already runs. The block editor, the Site Editor or an existing builder can produce a header-free campaign page without another plugin.
    • Install counts measure reach, not fit. Elementor shows 10+ million active installs and SeedProd 600,000+ on WordPress.org, and neither number says which tool suits your page.
    • The most common failure is a 404. Re-save Settings > Permalinks without changing the structure, and rebuild Elementor’s special Landing Page type as an ordinary Page if it clashes with your permalinks.
    • A page that is published can still be invisible. Check Settings > Reading for the homepage, purge every cache layer, and remove any leftover noindex.
    • On WooCommerce, check WooCommerce > Settings > Advanced > Page setup and keep Cart and Checkout out of the cache, or the landing page can look right and still fail to sell.

    Search for a WordPress landing page plugin and you get lists of ten tools, each called the best. None of them can tell you whether you need one. On most sites you don’t. The page you need is an ordinary WordPress Page with the header removed, one clear action and a working form. The editor or builder already on the site can make that.

    The bigger risk comes after launch. Landing pages tend to fail for boring reasons: a URL that returns a 404, a homepage that still shows blog posts, a cache serving last week’s headline, a noindex left over from staging. This article covers how to choose a route and how to stop those failures. For the build itself, see our guide on how to build a landing page in WordPress.

    Most sites don’t need a new plugin to build a landing page

    Start with what you already run. A landing page is a focused page with one job: collect a lead, register someone for a webinar or sell a product. WordPress gives you three ways to build one, and two of them are probably installed already.

    • The block editor or Site Editor. It’s free and part of core. On a block theme, you can make a template without the header and footer template parts and assign it to a single page.
    • The page builder you already have. Elementor, Beaver Builder, Divi and similar builders each have a blank or “Canvas” layout that drops the theme’s header and footer.
    • A dedicated landing-page plugin. SeedProd, LightStart and smaller tools add templates, coming-soon modes and campaign features.

    Liquid Web’s guide to creating landing pages makes the same point a careful developer would: if a builder is already on the site, use it instead of adding another system. Each extra builder brings its own assets, update cycle and ways to conflict with the theme. Our explainer on what a landing page builder really is covers the block-template route in detail.

    When a dedicated plugin earns its place

    Add a plugin when you need a specific feature the site lacks, not because a list said “high-converting templates.” The situations where a dedicated tool makes sense are narrow and easy to recognize.

    Your situationSensible routeThe tradeoff
    Block theme, one campaign page, a simple formSite Editor template plus a form block or form pluginFewer ready-made marketing widgets
    Site already built in a page builderSame builder, blank or Canvas layoutThe page stays tied to that builder
    Non-designer launching many short campaigns from templatesA dedicated landing-page pluginAnother plugin to update, license and test
    A/B testing, popups or funnel stepsA plugin or service built for that jobUsually paid, and adds scripts to the page

    Two caveats apply to any choice. Check what renewal costs at full price, because introductory pricing often ends after the first year. And check what the page looks like if the plugin is ever deactivated. A page built from core blocks still renders. A page built from a builder’s own elements usually does not.

    Why install counts and speed tests won’t pick for you

    The popularity numbers are real, but they measure different things. On WordPress.org’s “landing page” tag, Elementor lists 10+ million active installs and SeedProd 600,000+. Those figures count sites with the plugin active. They don’t count landing pages built, and they say nothing about fit.

    Market studies disagree too, because they use different denominators. W3Techs reports Elementor on 31.5% of WordPress sites as of October 2026. HTTP Archive’s 2025 Web Almanac says about 60% of WordPress sites use a page builder, and that Elementor’s share among those builders fell from about 56% in 2024 to 43% in 2025. Both can be true. One measures all WordPress sites and the other measures only sites that use a builder. Neither shows that Elementor is “growing” or “declining” in general.

    Speed comparisons are less reliable still. Published benchmarks rank the same builders in different orders depending on hosting, caching and test pages, and some are run by the vendors being compared. The only test that counts is your own page on your own hosting, measured before and after. In one r/webdev thread, a developer called switching builders “the absolute last thing” likely to speed up a slow site. Images, plugin count and hosting usually matter more.

    Why a published landing page still fails, in order of how often it happens

    Most landing-page problems come from configuration, not from a bad plugin. The causes below are ranked by how often they come up in support threads and official docs. That ranking is a pattern people report, not a measured rate.

    The URL returns a 404

    This is the complaint people raise most often. Confirm the page is published and that you’re testing its current URL. Then go to Settings > Permalinks and click Save Changes without touching anything. That rebuilds WordPress’s rewrite rules. WP Engine’s support docs recommend this reset and warn that changing the permalink structure on an established site can cause widespread 404s and hurt SEO.

    Elementor’s special “Landing Page” type has its own history here. In 2021, Elementor 3.4.3 sent every Landing Page to a 404 on sites with a custom date-and-name permalink, according to GitHub issue #16244. Rolling back to 3.4.2 fixed it in the reported test. The durable workaround is to save the design as a template, then use it on an ordinary WordPress Page with the Canvas layout. Ordinary Pages also appear in the homepage selector, and some builder-specific landing types do not.

    If the 404 survives a permalink save, test for a plugin conflict on staging, one plugin at a time (our guide to fixing plugins that stop working walks through it). After that, ask your host about rewrite rules. Don’t deactivate the builder itself to test, because every page built with it will break while it’s off.

    The homepage still shows posts or the old page

    Publishing a page doesn’t make it the homepage. WordPress’s Reading settings documentation says the front page shows your latest posts unless you go to Settings > Reading > Your homepage displays > A static page and pick the page. The Homepage and Posts page must be different pages. Our walkthrough on editing your WordPress homepage covers the theme files that can still override this.

    WordPress Reading settings setting a landing page as the static homepage
    Selecting a static page under the Reading settings assigns your custom design as the official front page of the site. · Source: www.youtube.com

    Landing-page plugins with site-wide “modes” add a second trap. A Coming Soon or Maintenance mode is a separate switch from publishing a page. Check the public URL while logged out, because logged-in admins often bypass those modes and see a site that visitors don’t.

    Your edits don’t show up

    A cache is serving an old copy. There are usually three layers: the caching plugin, the host’s server cache and the browser. A CDN makes four. Purge them in that order, then load the page in a private window. The usual mistake is clearing only the browser and deciding the edit failed. If the page still looks wrong, check for mixed content, meaning images or scripts loaded over http on an https page.

    Google can’t find it, or finds the wrong one

    A noindex left on from staging keeps a public campaign page out of search. Check both the page’s own SEO setting and any site-wide rule in your SEO plugin. The opposite mistake is using robots.txt to hide a private or test page. Google’s robots meta tag documentation explains that if robots.txt blocks a page, Google never reads its noindex, and the URL can still be indexed. Use noindex or a password for private pages and robots.txt for neither. Our guide to doing SEO on WordPress covers the per-page settings.

    The store page looks right but can’t take orders

    A designed product landing page isn’t the checkout. WooCommerce’s docs say the Cart and Checkout pages must be assigned under WooCommerce > Settings > Advanced > Page setup. If either page is missing, recreate it with the Cart or Checkout block. WooCommerce also says to exclude both pages from caching, because their content is specific to each visitor’s session. Before you send ad traffic, place a test order from the landing page all the way through.

    WooCommerce Advanced page setup with Cart and Checkout pages assigned for a landing page
    Designating the correct Cart and Checkout pages under the Advanced settings tab provides WooCommerce with the essential routing required to complete customer orders. · Source: hostarmada.com

    The form loses leads

    Template forms often use placeholders as labels, and those vanish as soon as someone types. The W3C’s Web Accessibility Initiative says each field needs a real label tied to it, with the label’s for matching the field’s id:

    <label for="email">Work email</label>
    <input type="email" id="email" name="email" required>

    Show required fields and errors in words, not only in red. Then submit the form yourself on the live URL while logged out, and confirm the entry reaches the inbox or CRM it’s meant for.

    When the real cost is waiting for someone to make the change

    The plugin decision is a one-time choice. The changes after launch keep coming: a new headline for this week’s ads, a button that should say something else, a form field to remove, a header to hide on one page. Each change is small. The process around each one, with a ticket, a queue, someone to make the edit and someone to check it, is not small.

    Agencies handle this with reusable templates, staging and a QA pass on forms, devices and redirects before launch. That works when you have a team. An agent shortens the queue for the routine part.

    Example request: “On the spring webinar page, change the headline to ‘Fix your checkout in 30 minutes’, change the button from ‘Learn more’ to ‘Save my seat’, and hide the site header and footer on that page only.”

    Before making the change, SiteSelf says what it’s about to change and whether you can undo it. It first checks which editor owns the page. If it’s a block-editor page, the agent edits the headline and button in the page content, then gives that one page a template without the header and footer parts, leaving every other page alone. Next it fetches the live page and reports in chat what changed and what it checked. The work is recorded.

    Access depends on the layer. Content and settings work goes through the SiteSelf Connector plugin from the WordPress.org directory. Changes to theme files or speed work need hosting (SSH) access. You can see how this works for layout and style requests on our page about design changes to your existing site.

    The limits are worth knowing before you rely on it. A page owned by Elementor, Divi or Beaver Builder is refused at the moment of work, with the reason given, so builder-made landing pages still need the builder. The check is a fetch of the changed page, not a full device test, so view the result on your phone yourself. Nothing is written to your analytics or ad platforms, so update the ad’s destination URL there if it changed. And the agent works on request. It won’t notice on its own that a page went down overnight. Cost is credit-based, and the pricing page has the details.

    Frequently asked questions

    Is there a free way to make a landing page in WordPress?

    Yes. The block editor and Site Editor are part of WordPress and cost nothing. Free versions of builders and landing-page plugins also exist, though popups, testing and some form features usually sit behind paid plans.

    How do I remove the header and footer from one page?

    In a builder, choose its blank or Canvas layout for that page. On a block theme, create a template in the Site Editor without the header and footer template parts and assign it to the page. Editing the shared header template instead changes every page on the site.

    Can my landing page be my homepage?

    Yes. Go to Settings > Reading, choose “A static page” and select it as the Homepage. If your builder’s landing-page type doesn’t appear in that list, rebuild the design on an ordinary Page and select that.

    Will a landing-page plugin slow my site down?

    It depends on your setup, and published benchmarks disagree. Measure your landing page before and after installing anything. Large images, extra scripts and tracking pixels often cost more speed than the builder does.

    Should a landing page keep the site navigation?

    For a page that receives paid traffic and has one goal, most teams remove it so visitors aren’t pulled away. Keep it if the page also has to work as a normal entry point to the rest of the site. No published data settles this either way, so it’s a judgment call based on where the traffic comes from.

    Do I need A/B testing built into the plugin?

    Only if you get enough traffic to reach a clear result. WordPress builders have limited built-in testing, and the dedicated tools that offer it are usually paid. A clear headline, a single call to action and a form that works matter more than a test run on a few hundred visits.

  • Apache web server security for WordPress sites

    Key takeaways

    • W3Techs puts Apache behind 26.5% of WordPress sites with a known web server, against 37.2% for Nginx and 25.3% for LiteSpeed. Nginx ignores .htaccess, and Apache’s default AllowOverride None ignores it too unless the host enables overrides.
    • The rule with the best backing is WordPress’s own FilesMatch block for wp-config.php, .htaccess, .htpasswd and debug.log. Put it outside the # BEGIN WordPress markers or WordPress may overwrite it.
    • Most breakage comes from the hardening itself. AH01797 in the log means an Apache access rule refused the request. ‘not allowed here’ means the directive can’t go in .htaccess. A ModSecurity 403 with a rule ID calls for an exception for that one rule, with the firewall left on.
    • Patchstack attributes 91% of the 11,334 new WordPress vulnerabilities it logged in 2025 to plugins. Server rules reduce risk, but they don’t replace updates, and they don’t clean a hacked site.
    • Do HTTPS in order: certificate, then WordPress URLs, then WooCommerce secure checkout, then direct redirects. Turn on HSTS only once every page loads over HTTPS.

    Apache is rarely the weak point on a WordPress site. Patchstack’s 2026 report counted 11,334 new WordPress vulnerabilities in 2025, and 91% of them were in plugins. Six were in core. So when people talk about Apache web server security for WordPress, they mostly mean configuration: a few rules that make a plugin flaw or an exposed file harder to exploit.

    Those rules also cause a lot of outages, because people paste them in without testing. This guide covers which ones help, how to tell whether your server reads them, and how to work out which rule broke your site.

    What Apache security actually covers on a WordPress site

    It covers four layers. Each one sits next to WordPress’s own security (updates, accounts, backups), not in place of it:

    • Access rules in Apache’s configuration or in .htaccess: blocking sensitive files, turning off directory listings, stopping PHP from running in uploads.
    • HTTPS and redirects: the certificate, the WordPress URL settings, and HTTP-to-HTTPS rules.
    • Security headers: HSTS, Content Security Policy and frame controls.
    • A server-level firewall such as ModSecurity. WordPress’s Hardening handbook recommends one and treats it as separate from plugin firewalls like Wordfence, which run inside WordPress.

    Check that Apache rules apply to your site at all

    Many of them won’t. W3Techs puts Apache at 26.5% of WordPress sites with a known web server. Nginx is at 37.2% and LiteSpeed at 25.3%. Nginx doesn’t read .htaccess, so a rule that works on one host does nothing on another and shows no error. Our guide to setting up .htaccess redirects runs into the same problem.

    Running Apache isn’t enough on its own. Apache’s documentation says the AllowOverride default is None, which means it ignores .htaccess files unless the host allows them. Hosts can also allow some kinds of directive and not others. If you use a directive that isn’t allowed, you get a 500 error instead of protection.

    The simplest check is a support ticket. Ask your host three things:

    • Which web server serves the site?
    • Which AllowOverride classes are enabled?
    • Are mod_rewrite and mod_headers loaded?

    If you control the server, put site-wide rules in the main configuration. Apache’s docs say that gives tighter control than per-directory files.

    Which rules are worth adding

    Add a few targeted rules, one at a time, and test after each. Copied “maximum security” blocks and good grades from header scanners don’t show that a rule suits your site.

    Deny web access to sensitive files

    WordPress’s Apache handbook documents this rule for the root .htaccess:

    <FilesMatch "^(wp-config\.php|\.htaccess|\.htpasswd|debug\.log)$">
      Require all denied
    </FilesMatch>

    The handbook also suggests blocking install.php once the site is installed. Require all denied is Apache 2.4 syntax. Older guides use Deny from all, which is the 2.2 form, so match the syntax to your server version. Blocking wp-config.php over the web doesn’t replace tight file permissions on it.

    Turn off directory listings and PHP in uploads

    When a folder has no index file, Apache can list everything in it. Options -Indexes turns that off, but only if the host allows Options overrides.

    For uploads, block PHP from running instead of blocking the whole folder, which would break images. In wp-content/uploads/.htaccess:

    <FilesMatch "\.(php|phtml|phar)$">
      Require all denied
    </FilesMatch>

    This doesn’t make private files private. Anything else in uploads can still be loaded by anyone with its URL.

    Know the documented ways these rules break things

    WordPress’s Hardening handbook lists the failure modes plainly:

    • Password-protecting /wp-admin/ carelessly breaks admin-ajax.php. Many front-end features depend on that file.
    • The wp-includes rule stops ms-files.php generating images on Multisite.
    • Custom rules belong outside the # BEGIN WordPress / # END WordPress markers, because WordPress may overwrite anything between them.

    Moving wp-config.php has disputed value. The handbook only documents moving it one level above the install, and it warns that doing it carelessly can create serious holes.

    Permissions follow the same least-privilege logic. WordPress’s permissions page gives 755 for directories and 644 for files as examples, not fixed rules. It notes that .htaccess has to be writable if you want WordPress to update rewrite rules. Never use 777. Hiding the WordPress version is fine to do, but the handbook calls obscurity an unsound main strategy.

    Get HTTPS right, in this order

    Turning on HTTPS is a sequence of steps. Force it before the certificate and settings are ready and the site can lock everyone out. WooCommerce’s SSL documentation says most payment gateways require SSL. The order:

    1. Install the certificate and check it is valid on every hostname.
    2. Set WordPress Address and Site Address to https:// under Settings > General.
    3. On a store, turn on secure checkout under WooCommerce > Settings > Advanced. It covers Checkout, My Account and the Pay endpoint.
    4. Add an HTTP-to-HTTPS redirect that goes straight to the final URL, with no chain.
    5. Make sure canonicals use HTTPS. Google Search Central prefers HTTPS canonicals. It says an invalid certificate, a redirect through HTTP or an HTTP canonical are conflicting signals.
    6. Turn on HSTS last, once every page loads over HTTPS.

    Why headers and CSP need one owner

    Set each header in one place only: the server config, the cache layer or a plugin. Headers added from PHP don’t reach cached pages or static files that never touch WordPress, so the policy visitors get can differ from the one you wrote. Setting a header in two places gives you duplicates. After any change, purge the cache and check the live headers on a cached page and an uncached one.

    Content Security Policy goes wrong in two directions. Make it too strict and it blocks legitimate scripts. “Fix” the violation reports by allowing every origin or unsafe-eval and the policy stops protecting much. Start it in Report-Only mode and click through the real site: forms, embeds, analytics, logged-in views and, on a store, the full checkout and payment flow. Enforce it only after that.

    When hardening breaks the site, the log names the rule

    Most hardening failures are self-inflicted. A rule is too broad, it isn’t allowed in .htaccess, or it clashes with another rule. The Apache error log (in cPanel, usually under Metrics > Errors) often tells you which one.

    What you seeLog lineLikely cause
    500 error after an edit<Directory not allowed hereA server-only directive pasted into .htaccess
    500 error after adding headersInvalid command 'Header'mod_headers isn’t loaded
    500 or rules ignoredRewriteEngine not allowed hereOverrides not permitted
    403 on a path that should workAH01797: client denied by server configurationAn Apache access rule matched
    403 or 406 page branded by the hostModSecurity: Access denied with code 403 plus a rule IDA server firewall false positive
    Apache error log showing AH01797 client denied by server configuration
    Apache error logs record the AH01797 code alongside the exact requested path whenever an access restriction blocks an incoming request. · Source: www.budgetvm.com

    For a 500 after editing .htaccess:

    1. Download a copy of the file.
    2. Read the error log.
    3. Comment out the newest rules.
    4. If the site still fails, rename the file to .htaccess-old as a test.
    5. Once the site loads, rebuild WordPress’s block by saving Settings > Permalinks.

    Removing the file brings the site back but drops your redirects, so put them back afterwards. Our white screen guide goes through the same order for fatal errors.

    If pretty permalinks return 404s, WordPress’s Common errors page points to mod_rewrite being off or the rules being missing. Save the permalinks page again. If that fails, save a different structure, then switch back.

    Firewall false positives need a narrow fix. In one WordPress.org thread, ModSecurity rule 214540 in a COMODO rule set blocked the Google Tag Manager iframe after GTM4WP 1.16. A SecRuleRemoveById exception for that one rule fixed the 403. On shared hosting, the host adds that exception. Switching the whole firewall off is useful as a quick test, never as the fix. Plugin firewalls work the same way: allowlist the one request that was blocked, then turn protection back on.

    Don’t assume every symptom is a server block, either. In another thread, a store owner whose customers couldn’t check out found AH01797 lines from directory-hardening rules the host had added to wp-content and uploads. The replacement rules didn’t fix checkout. The log line and the customer complaint were two separate problems.

    Reading the log and fixing the rule is the kind of work SiteSelf’s agent does on request through WordPress bug fixes. Editing .htaccess needs hosting (SSH) access, and the agent reports what it changed and what it checked.

    Hardening won’t clean a hacked site

    Malicious .htaccess rules are a common sign of infection. Sucuri found allow/deny rules tied to Japanese SEO spam on 10.07% of the infected sites it cleaned in 2023. That sample isn’t limited to WordPress or Apache. WordPress.org support threads show the other side too: .htaccess files reinfected again and again, despite security plugins, a CDN and read-only permissions. The infection was still somewhere else on the site.

    If rules keep reappearing, clean up first, then harden. Our guide to malware removal that holds covers finding the entry point. Before you restore anything, check what your backup plugin actually covers, because restoring a backup that already contains the malware brings it straight back.

    When to stop and ask the host

    Stop when the fix needs something you can’t reach: the main Apache config, a ModSecurity exception, module changes or the Apache version itself. On shared and managed hosting, all of those belong to the host. Send a specific request with the URL, the time, the log line and the rule ID. A vague “please harden Apache” ticket won’t get you far.

    A bare VPS is different. Patching, certificates, backups and PHP versions are your job or your developer’s. If nobody has that time, managed hosting costs less than the outage. On a store, take payments through an external gateway so card data never sits on the server.

    Hosting file manager showing the WordPress .htaccess file for Apache security rules
    Enabling hidden files in your hosting file manager ensures the .htaccess file appears in the directory list for editing. · Source: www.hostgator.com

    Frequently asked questions

    Does .htaccess work on Nginx?

    No. Nginx ignores .htaccess completely, so the same protections have to be written into the Nginx server configuration, usually by the host. Plugins that rely on .htaccess for access control can leave an Nginx site unprotected without showing any error.

    Does LiteSpeed read Apache .htaccess rules?

    LiteSpeed reads Apache-style .htaccess files, and WordPress’s rewrite block generally works there. Don’t assume every Apache directive behaves the same way. Test each security rule on the live site and check the error log.

    Should I block xmlrpc.php?

    Block it only if nothing uses it. Some mobile apps, publishing tools and integrations still depend on XML-RPC, so check what connects to the site before you block it, and test those connections afterwards.

    Is 777 ever acceptable to fix a failing update?

    No. 777 lets any user on the server write to the file or folder. If updates fail, the cause is usually file ownership, and the host can fix that properly. WordPress’s permissions page gives 755 and 644 as starting examples.

    Does noindex keep a new site hidden from attackers?

    No. Noindex only affects search results. Automated scanners probe every public IP and hostname. Build the site locally or behind a password until launch, and add the access rules before it goes public.

    Should I update Apache myself?

    Only if you manage the server. On shared or managed hosting, the host patches Apache and its modules. Ask which version you are on and how quickly they apply security releases.

  • What a WordPress maintenance package should cover

    Key takeaways

    • Neither WordPress.org nor WooCommerce defines a maintenance package. Both document a routine: full backup, staging test for significant updates, update, verify key functions.
    • WooCommerce says a monthly update cadence works for most stores, with security fixes applied sooner, and it asks you to test cart, checkout, payments, shipping, taxes and order emails on staging first.
    • A backup counts only if it covers files and database, lives off the server and has been restored at least once. WordPress’s handbook suggests 3 to 5 copies in different places.
    • Most package disputes come down to four questions: who fixes a broken update, whether hack cleanup is included, what counts as an edit, and how fast anyone responds.
    • In the State of Enterprise WordPress 2024 survey, 62% of organisations said ongoing maintenance and updates were billed on top of the initial fee.

    Take two WordPress sites, both described as “maintained”. On the first, a tool applies every plugin update automatically on the first of the month. On the second, someone backs up the site, runs the updates on a staging copy, submits the contact form, puts a product through checkout, and only then updates the live site. Both owners pay a monthly fee. Only the second owner knows the site works.

    That gap is what this article is about. The phrase “maintenance package” covers both setups, plus everything in between, so price and plan names tell you almost nothing. What you need is the routine underneath and the questions that show how much of it a provider really does.

    Is there a standard WordPress maintenance package?

    No. WordPress.org and WooCommerce don’t define a package. They describe a routine: make a current backup of files and database, test significant updates on a staging copy, apply the updates, then check that the important parts of the site still work. Everything sold as a maintenance plan, care plan or retainer is some version of that routine with other services attached.

    The attached services are where plans differ. One plan might be automated updates and a weekly backup. Another adds uptime alerts, security scans, an hour of edits, hosting, staging tests and someone who answers the phone when checkout fails. Our broader piece on what website maintenance packages cover looks at the commercial side across platforms. This one stays with WordPress and the work itself.

    What routine sits underneath every package?

    Four steps, done in order, every time something significant changes. If a plan skips one, it is a cheaper plan, and you should know which step is missing.

    Updates are the main job and the main source of breakage

    Core, plugin and theme updates take up most of the hours in any package, and they cause most of the problems. A plugin update can fix a security hole and still break a form. A theme update can change a template your child theme overrides. WordPress’s own troubleshooting documentation names faulty or incompatible plugins and themes as the usual cause of fatal errors after an update.

    How often to update is the one point practitioners argue about. WooCommerce’s update guide says a monthly cadence works well for most stores, with security fixes or broken functionality handled sooner. Many freelancers update weekly or every two weeks. Some wait a few days after a release to see whether problems turn up in the support forums. Every source agrees on the split: apply security patches promptly, and test routine updates before they reach the live site. Large batches of updates done together are harder to debug when one of them fails.

    Themes follow the same mechanics with a few extra traps. Our guide to updating a WordPress theme safely covers those.

    WordPress maintenance package updates screen listing pending plugin updates
    Multiple pending update alerts in the WordPress dashboard highlight the routine maintenance cycle where unexpected site conflicts most often begin. · Source: crocoblock.com

    A backup only counts if it restores

    WordPress keeps your site in two places: the wp-content folder (themes, plugins, uploads) and the database (posts, pages, settings, and on a store, products and orders). A backup that covers only one of them is half a backup. WooCommerce’s backup documentation adds a common mistake: the WordPress XML export does not include the database tables for orders, products or WooCommerce settings, so it is not a backup of a store.

    The WordPress Advanced Administration Handbook suggests weekly backups for smaller, low-activity sites and daily backups for busy ones, with 3 to 5 recent copies kept in different locations. Then comes the step most plans don’t mention: test a restore. A job that reports success proves a file was written. It does not prove you can get the site back. Our explainer on what a backup plugin misses goes through the usual gaps.

    Applied is not the same as verified

    This is where cheap maintenance and good maintenance part ways. An update that ran, a backup that exists and an uptime check that returns “OK” all say something happened. None of them says the contact form still sends email.

    The stuck “Briefly unavailable for scheduled maintenance” message is a good example. WordPress creates a .maintenance file in the site root while it updates, and an interrupted update leaves the file behind. Deleting it removes the message. WordPress.org’s updating guide is clear that you then have to run the update again, because the plugin may be half old files and half new. Clearing the symptom is not the fix. Our guide to plugins that stop working after an update walks through the full recovery.

    Verification means opening the pages that make money or bring in leads and using them. Do it as a logged-out visitor as well as an admin, because caching and permissions often hide problems from the person who made the change.

    Why does a WooCommerce store need a stricter package?

    When a brochure site breaks, you lose a few enquiries. When a store breaks, you lose orders, and some of the fixes cause damage of their own. WooCommerce’s documentation asks for more than a generic plan usually provides:

    • Test on staging before the live store: product pages, cart, checkout, payments, shipping, taxes, order emails and anything specific to your extensions.
    • Some releases need a database update after the plugin files update. Don’t navigate away, refresh or start another update partway through, and don’t run the database update without a current backup.
    • Don’t run several major updates together unless you tested that exact set together on staging.

    Rollback is the part that catches people. WooCommerce warns that going back to an older version after the database schema changed can cause data inconsistencies, so a rollback needs a database backup that matches the version you return to. Restoring an older backup to a live store also wipes out every order placed since that backup. If you use WooCommerce Subscriptions, its restore guide lists the knock-on effects: missing renewal orders and wrong payment dates.

    So a store package needs answers to three questions. Who tests checkout after an update, and how? What happens to orders that come in between the backup and the restore? Who handles database updates?

    WooCommerce database update notice in the WordPress admin during store maintenance
    Major WooCommerce updates frequently trigger an admin alert requiring a database migration that should only be executed after taking a complete backup. · Source: woocommerce.com

    Where does package scope usually go wrong?

    The technical work is well documented. The disputes come from scope. People in freelancer and agency forums give the same advice again and again: keep technical maintenance separate from content edits, development and SEO work, and never promise “unlimited” anything. The State of Enterprise WordPress 2024 survey found that 62% of organisations were charged extra for ongoing maintenance and updates rather than having them included in the initial fee. Bigger organisations misjudge this too.

    Line in the packageThe question that shows real scopeThe usual gap
    UpdatesAre significant updates tested on staging, and what gets checked afterward?Budget plans often update the live site directly and check nothing beyond “the page loads”.
    Broken updateIf an update breaks the site, is the fix included or billed by the hour?The plan covers applying updates, not repairing what they break.
    BackupsFiles and database? Stored where? When was the last test restore, and how long does a restore take?Backups stored on the same server as the site, never restored.
    SecurityIs cleaning up a hacked site included, or only scanning?Many providers sell malware removal as a separate one-time service.
    HostingIf the host and the maintainer disagree about the cause, who owns the problem?The host looks after the server and won’t troubleshoot your plugins.
    EditsWhat counts as an edit, how many hours are included, and what is the rate after that?“Small changes” with no definition, which ends in an argument or an invoice.
    ReportingWill you see which updates ran, what was checked and what is still unresolved?An invoice is the only evidence any work happened.

    Two of these trip people up more than the others. First, hosting is not maintenance, even managed hosting. A good host may handle core updates and server backups, but a plugin conflict on your site is usually your problem or your developer’s. Second, monitoring is not cleanup. A scan that finds malware is the start of an incident, and a plan can include the alert without including the work that follows.

    Providers have one rule of their own worth knowing: audit a site before taking it on. A five-year-old store with skipped upgrades and no original developer is a project, not a monthly plan. A provider who quotes it like a monthly plan will lose money on it or cut corners.

    When is a paid plan not worth it?

    If your site is a few pages that rarely change, has no forms that matter and takes no payments, you can reasonably do the routine yourself. Keep full backups off the server, update every few weeks, and click through the site afterward. Guides that estimate the time put routine updates and backup checks at well under an hour a week on a simple site.

    The case for paying gets stronger as two things grow: how much money flows through the site, and how many plugins sit between a visitor and that money. What a retainer really buys is someone already on the hook when something breaks. Quiet months are normal. The value shows up in the month an update takes checkout down.

    Whichever way you go, take things away now and then. Plugin lists grow for years, and every plugin you remove is one less update to test.

    How the work changes when an agent does it

    Most maintenance requests are small: update these plugins, find out why the form stopped sending, change this setting back. The process around them is not small. Someone writes a ticket, someone else schedules it, the work happens days later, and the report says “done” without saying what was checked. SiteSelf is built for the request itself. You say what needs doing in chat, the agent does it on the live site, checks the result and reports what changed. This is what plugin updates handled through chat look like.

    Example request: “Update the plugins on our store that have updates waiting, but leave WooCommerce itself until after the holiday sale. Tell me what each update changes before you run it, then check the shop page, a product page and the checkout page.”

    What the agent would do: list the pending updates, read the changelogs and flag anything that touches payments, shipping or forms, tell you what is about to change and whether it can be undone, apply the updates, then fetch each page you named and report back in plain language. The work is recorded, so next month you can see what changed.

    What it checks: it fetches the changed pages and confirms they load and show what they should. That is not a screenshot, a test order or a test on every device. For a store, still run a test purchase yourself after any update that touches checkout.

    What access it needs: the SiteSelf Connector plugin from the WordPress.org directory for plugin and settings work. Hosting (SSH) access for anything in files or logs, such as tracing a fatal error after an update or clearing a leftover .maintenance file.

    What it does not do: it works on request only, with nothing scheduled and no monitoring, so it won’t notice a broken site on its own or run next month’s updates unless you ask. It reads third-party systems like analytics at most and writes nothing to them. Pages owned by Elementor, Divi or Beaver Builder are refused at the moment of work, with the reason. There is no approval queue before publishing, so the boundary is in what you ask for and in the agent saying what it will change before it does.

    WordPress briefly unavailable for scheduled maintenance message after an interrupted update
    When an update stalls, WordPress locks visitors out behind a brief maintenance notice that persists until the underlying lock file is cleared. · Source: kinsta.com

    Frequently asked questions

    Do I still need maintenance if I have managed WordPress hosting?

    Usually yes, at least for plugins and themes. Managed hosts look after the server and often handle core updates and backups, but most won’t troubleshoot a conflict between plugins you installed. Ask your host exactly where its responsibility ends.

    Is a maintenance mode plugin the same as a maintenance package?

    No. A maintenance mode plugin shows visitors a holding page while you work on the site. It doesn’t update, back up or fix anything. The shared word confuses many owners searching for help.

    Does a maintenance plan include cleaning up a hacked site?

    Often not. Many providers include scanning and alerts in the monthly fee and sell malware removal as a separate one-time service. Get the answer in writing before you need it.

    How often should a WordPress site be updated?

    Apply security releases promptly. For routine updates, WooCommerce suggests about monthly for stores, and many freelancers update weekly or every two weeks. Whatever the schedule, back up first and test anything significant before it reaches the live site.

    Why do maintenance plan prices vary so much?

    Because the scope varies. A plan that runs automated updates is a different product from one that tests on staging, repairs what breaks and responds within the hour. Compare deliverables line by line. If you are weighing SiteSelf’s credit-based model, the pricing page explains how credits work.

    Can I maintain a WordPress site myself?

    Yes. The routine is documented and the tools are free or cheap. The hard part is the occasional failure that takes hours to diagnose. Decide in advance who you would call when that happens.

  • How to modify the header in WordPress

    Key takeaways

    • On a block theme the header is a template part under Appearance > Editor. On a classic theme it is under Appearance > Customize. If Elementor’s Theme Builder has a published header, Elementor controls it.
    • Creating a menu does not put it in a block-theme header. You have to select the Navigation block and choose that menu.
    • Verification tags and analytics scripts belong in a code-insertion plugin such as WPCode, with the full script tags included, not in a parent theme’s header.php.
    • For “Cannot modify header information”, fix the file and line after “output started at”. The file the warning names first is usually only where the failure showed up.
    • If a header saves but looks unchanged, check four things in order: the editor you used, every cache layer, the page template (Elementor Canvas hides the header), then plugin conflicts.

    Four different jobs show up under the words “modify header” in WordPress. Someone wants a new logo or menu. Someone else needs to paste a Google verification tag. A third person needs a security header from the server. A fourth is staring at a PHP warning that says “Cannot modify header information.” Each job happens in a different place, and the most common failure is a correct edit made in the place that doesn’t control the live site.

    Which header are you trying to change?

    Pick your row before you open anything.

    What you wantWhat it isWhere you change it
    Logo, menu, layout, colours, sticky behaviourThe visible site headerSite Editor, Customizer or theme options, or a page builder
    Verification tag, analytics script, meta tagThe HTML <head>A code-insertion plugin, or a child theme
    Security, caching or CORS headersHTTP response headersThe Redirection plugin, your host’s panel, or server config
    “Cannot modify header information – headers already sent”A PHP errorThe file and line after “output started at”

    Find out what controls your visible header first

    Open the Appearance menu in wp-admin. If you see Editor, you’re on a block theme and the header is a template part. If you see Customize and no Editor, it’s a classic theme. Our guide to telling block and classic themes apart walks through the same check.

    Then check for a builder. If Templates > Theme Builder in Elementor has a published header, Elementor controls the header and the theme’s settings won’t change it. Some commercial themes have their own panel too. One Avada user on Reddit found the controls under Appearance > Theme Options > Header after searching everywhere else.

    How to edit the header in a block theme

    1. Go to Appearance > Editor.
    2. Open Patterns, then Template Parts, then Header. Labels shift a little between WordPress versions, but the header is always a template part.
    3. Edit the blocks: Site Logo, Site Title, Navigation and any button or announcement row.
    4. To change the menu, select the Navigation block and choose the menu in its settings. Creating a menu somewhere else doesn’t put it in the header.
    5. Click Save. The change applies to every template that uses this header part.

    Here’s a catch developers run into: after you save, WordPress keeps your version in the database and uses it instead of the theme’s parts/header.html. Editing that file later changes nothing until you reset the template part’s customizations in the Site Editor. The guide to WordPress drop-down menus covers the Navigation block in more detail.

    How to edit the header in a classic theme

    Go to Appearance > Customize. Three panels do most of the work:

    • Site Identity: logo, site title and tagline. If an oversized title appears above your menu, untick “Display Site Title and Tagline” here.
    • Menus: assign a menu to the header location the theme registers.
    • Header Image: only appears if the theme supports a custom header.

    Click Publish when the preview looks right. A classic theme only lets you change what it exposes. If the panel you need isn’t there, you can either live with the limit or make a code change in a child theme. You can’t fix it from the settings screen.

    How to edit an Elementor header

    Go to Templates > Theme Builder > Header, edit the template and click Publish. Elementor then asks for display conditions, such as the entire site or specific pages. A header that shows on some pages and not others is usually a condition problem. It’s rarely a design problem.

    Check the page template as well. Elementor Canvas deliberately leaves out the header and footer. In a resolved WordPress.org support thread, switching a page from Canvas to Elementor Full Width brought a missing header back.

    How to add code to the head without touching theme files

    Use a code-insertion plugin. In WPCode, the steps are:

    1. Go to Code Snippets > Header & Footer.
    2. Paste head code (verification tags, analytics) into the Header field. Include the opening and closing <script> or <meta> tags. If you leave out a script wrapper, the code can print on the page as plain text.
    3. Paste code the provider says belongs right after <body> into the Body field. This only works if your theme calls wp_body_open, the hook WordPress fires after the opening body tag.
    4. Save, then view the page source on the live site and search for your tag.

    WPCode’s documentation says code added this way stays in place when you switch themes, because it lives in the plugin. A pasted tag in header.php disappears with the next theme update.

    WPCode Header and Footer screen for adding code to the WordPress header
    Pasting complete script tags directly into the Header field ensures custom code loads cleanly inside the site’s head section. · Source: wpcode.com

    When you do need header.php, use a child theme

    In a classic theme, header.php contains the document head and calls wp_head(). Plugins print their scripts and meta tags through that hook. Edit the parent theme’s copy and the next update overwrites it.

    Back up first. Then create a child theme. Often you don’t need to copy header.php at all, because a hook in the child theme’s functions.php is smaller and safer:

    add_action( 'wp_head', function () {
        echo '<meta name="example-verification" content="abc123">' . "\n";
    } );

    Only copy header.php into the child theme when you need to change its markup. Don’t copy the parent’s functions.php. WordPress’s Theme Handbook warns that duplicated function names cause fatal errors. Our article on theme customization that survives updates covers the child-theme setup.

    Why the header saved but nothing changed

    These usually fail silently, with no error. Check them roughly in this order:

    1. You edited the wrong layer. The live header comes from a Site Editor template part, a builder template or a database customization, but the edit went into header.php, a pattern or the page content.
    2. A cache is serving the old header. WordPress.org’s FAQ lists browser cache, server-side cache and caching plugins as separate causes. Add your CDN and object cache to that list. Logged-in users often skip the page cache, so check in a private window. On Elementor, regenerate CSS and data after clearing caches.
    3. The page template hides the header. Elementor Canvas, a theme’s “blank” template, or display conditions that leave the page out.
    4. A conflict. Two header systems are active, or a plugin interferes. In one WordPress.org thread, a Polylang connector hid Elementor headers until the display conditions were saved again. Switch to a default theme and turn plugins off one at a time to find it.

    How to fix “Cannot modify header information”

    This PHP warning means something printed output before WordPress tried to send a header, a cookie or a redirect. The message looks like this:

    Warning: Cannot modify header information - headers already sent by
    (output started at /wp-content/themes/child/functions.php:34)
    in /wp-includes/pluggable.php on line 1450

    Fix the file after “output started at”, not the one after “in”. WordPress’s Advanced Administration Handbook names the usual culprits:

    • blank lines or spaces before <?php or after a closing ?>;
    • a UTF-8 byte order mark (BOM) your editor saved invisibly;
    • a redirect that runs after the page has started printing.

    In a PHP-only file, leave out the closing ?> completely. For redirects, run them on template_redirect and stop execution, because wp_redirect() doesn’t exit on its own:

    add_action( 'template_redirect', function () {
        if ( is_page( 'old-offer' ) ) {
            wp_redirect( home_url( '/new-offer/' ), 301 );
            exit;
        }
    } );

    If a core file is damaged, replace it from a backup or a fresh WordPress download. The guide to redirecting a page without losing traffic covers the non-code routes.

    How to add HTTP response headers

    These are set at the server, not in the page. With the Redirection plugin, go to Tools > Redirection > Site and use the HTTP Headers section. Add a header name and value, choose whether it applies to the whole site or only to redirects, and save. Picking “redirects” for a header meant for every page is a common mistake.

    Purge caches. Then open your browser’s developer tools, reload, and read the response headers in the Network tab. Some managed hosts restrict certain headers, so check your host’s panel if one won’t stick.

    What a correct result looks like

    Check the live site in a private window, logged out, at phone width. Open and close the mobile menu, scroll to test any sticky behaviour, and make sure the sticky header doesn’t cover page titles. Then tab through the header with the keyboard.

    The W3C’s accessibility tutorials recommend putting the main menu in a labelled <nav> region. A <header> nested inside an <article> or <section> is not the page-wide banner. Custom header markup should keep both points intact.

    WordPress header checked at phone width with the mobile menu open
    Testing the mobile viewport confirms that the slide-out navigation opens smoothly and displays nested menu links without breaking the layout. · Source: wordpress.org

    When the theme can’t produce the header you want

    Sometimes there’s no setting to find. In a 2026 WordPress.org thread, a Storefront user wanted the account, cart and search on one line. Storefront doesn’t do that by default. Moving My Account into the primary menu got partway there, and the owner kept the simpler header.

    At that point you have three options: accept the theme’s layout, rebuild the header in a builder, or have the markup changed in a child theme. If you want the third option done for you, SiteSelf makes header and layout changes on an existing site from a chat request. It needs hosting access for template files, and it refuses headers owned by Elementor, Divi or Beaver Builder.

    Frequently asked questions

    Can I use a different header on different pages?

    On a block theme, create a second header template part and use it in the templates that need it. In Elementor, publish a second header and give it its own display conditions. Classic themes only offer this if the theme supports it.

    Can I modify the header without a plugin?

    For visual changes, usually yes, through the Site Editor or the Customizer. For scripts and meta tags, a plugin is the simplest route. The alternative is a wp_head hook in a child theme, which needs file access.

    Will a theme update erase my header changes?

    Edits to the parent theme’s files will be erased. Site Editor changes, Customizer settings, builder templates and code-plugin snippets are stored separately and survive theme updates. Child-theme files survive as well.

    Why is my header suddenly taller than before?

    Check the logo file first. Transparent padding inside the image counts as part of the logo’s size, so cropping the image often fixes it. If the logo is fine, look at padding on the header group or a newly added announcement row.

    How do I add noindex to a few specific posts?

    Use your SEO plugin’s per-post setting if you have one. Otherwise, add a conditional wp_head hook in a child theme, or a snippet in a code plugin with page conditions.

  • How to manage multiple WordPress websites

    Key takeaways

    • “Multiple sites” covers four different setups: separate installs, a Multisite network, one WooCommerce store with several locations, and separate stores that share data. Each one needs a different tool.
    • WordPress’s own Multisite handbook starts with “Do you really need a network?” For unrelated client sites, the usual answer is separate installs connected to a dashboard like MainWP or ManageWP.
    • A dashboard reporting a finished update means the update ran. It does not mean the contact form, the checkout or the templates still work. Check each site based on its risk.
    • A dashboard holds admin access to every connected site, so it becomes the most valuable login you have. Lock it down like one.
    • Dashboards handle maintenance, not content changes, store reporting or the duplicate-site rules in Google’s spam policies. Plan for those separately.

    Here’s a typical Tuesday. The phone number needs changing on three client sites, two others need a campaign page, a WooCommerce promotion has to go live, and a contact form somewhere stopped sending notifications. Every one of those sites has its own login, theme, plugins and host, plus years of earlier changes nobody wrote down.

    A longer spreadsheet won’t fix that. What helps is three decisions made in order: how the sites are set up, how routine maintenance runs across all of them, and who handles the exceptions that maintenance turns up. Most advice starts with the second one. Start with the first.

    Which kind of “multiple sites” do you actually have?

    “Managing multiple WordPress sites” can mean four different setups, and each needs a different tool. Mixing them up is the most expensive mistake in this area, because undoing a bad setup choice later means a migration.

    Your situationThe setup that fitsWhat it does not do
    Independent sites: different clients, brands or ownersSeparate installs, managed from a central dashboard or your host’s panelShare content, users or plugins between sites
    Related sites that share a design, plugins and adminsWordPress Multisite: one installation running a network of sitesKeep sites isolated, or share data between them
    One shop with several physical locationsA location extension inside one WooCommerce storeConnect shops that already run as separate sites
    Separate WooCommerce stores that need the same products or ordersA sync extension that connects the stores through the WooCommerce REST APIHandle updates, backups or security

    Multisite is the option people choose too quickly. WordPress’s own guide to preparing a network opens with “Do you really need a network?” before it lists any requirements. A network runs one copy of WordPress core. Plugins and themes are installed at network level, and every site depends on the same server. That’s convenient for a group of regional sites built from one design system. It’s a liability for twelve unrelated clients, because one bad plugin update reaches all of them, and moving one client out later is real work. If your sites really do belong together, our guide to WordPress Multisite installation walks through the setup.

    The store options get confused just as often. WooCommerce’s Multi Store Manager adds location-based shops with their own products, prices, stock and orders, all inside one WooCommerce site. Installing it won’t merge two shops you already run separately. For that you need Products and Orders Sync or something similar, with API keys on each store.

    Why separate installs plus a dashboard is the usual answer

    For independent sites, keep each one as its own installation and connect them all to one control panel. Each site keeps its own database, its own update timing and its own backups. The dashboard takes away the repeated logins.

    The two names that come up most often in practitioner threads work differently:

    • MainWP is self-hosted. You install the MainWP Dashboard plugin on a WordPress site you control, then put the MainWP Child plugin on each site you want to manage. You own the data and the server, and you also maintain both.
    • ManageWP is hosted. You connect each site through the ManageWP Worker plugin and run everything from their web app. It’s less to maintain, and you depend on their service.

    Many managed hosts also include a multi-site panel for the sites they host. That’s often enough if every site lives with one host. Whichever tool you pick, the core features are similar: bulk updates for core, plugins and themes, backups, uptime checks, security scans and client reports.

    A dashboard holds admin-level access to every connected site, which makes it the most valuable account you run. Practitioners on r/Wordpress have described incidents where one compromised dashboard account or an unpatched management plugin exposed every connected client site. Treat the dashboard login like the keys to your whole client list. Use two-factor authentication, keep the list of people who can log in short, update the dashboard first, and remove sites you no longer look after.

    When a site refuses to connect

    Most connection failures come from a security layer sitting in front of the site, not from a missing plugin. A firewall, a host’s web application firewall, a security plugin or a CDN sees the dashboard’s requests as automated traffic and drops them. MainWP’s connection test reference links each HTTP status code to a likely cause. Roughly, a 403 means something refused the request, and a 404 means the child plugin isn’t answering.

    The fix is to find the rule that blocked the request and ask the host to allow the dashboard’s IP address. Turning protection off until the site connects is not the fix, because it leaves the site exposed. If the site recently moved hosts or domains, check that DNS and the site URL point to the new place before you assume anything is broken.

    Why the update is easy and the check is hard

    Running updates across 50 sites takes minutes. Confirming that 50 sites still work afterwards is the actual job. Practitioners agree on this more than anything else. A dashboard that reports “updated” is telling you the update ran. It has no idea whether the booking form on one site now fails without any error.

    Checking every page by hand doesn’t pay on a care plan. Skipping checks means your clients find the breakage first. The workable middle is to check each site based on how much damage a failure would do:

    1. Back up first, and know you can restore. WordPress.org’s plugin documentation says to make a current backup before updating. A backup job that reports success only proves a file was written, so test a restore now and then. Our explainer on what a backup plugin covers lists what “full backup” often leaves out.
    2. Sync, then update in batches. Refresh the dashboard’s data before you act on it. Update brochure sites together, and keep stores and custom-coded sites in their own group.
    3. Check the pages that make money. On simple sites, load the homepage, the contact page and any form. On stores, test the cart and checkout, and run a test order if the update touched payments.
    4. Use staging for high-risk sites. Test WooCommerce, membership and heavily customized sites on a copy first. Some teams also hold major releases for a few days.
    5. Write down the exceptions. If one site out of forty fails, the batch didn’t succeed. Record which site failed, what broke and what you did about it.

    Learn what failure looks like, because a bulk run can leave several sites in the same state. “Briefly unavailable for scheduled maintenance. Please check back in a minute.” usually means an update stopped halfway and left a .maintenance file in the site root. “There has been a critical error on this website.” means PHP hit a fatal error. The details go to the admin email address or to wp-content/debug.log if debugging is on. WordPress’s common errors handbook covers both. Our guide to fixing plugins that stopped working goes through the cleanup.

    WordPress briefly unavailable for scheduled maintenance message after a failed bulk update
    An interrupted update traps WordPress in maintenance mode, displaying this generic notice until the lingering temporary file is manually cleared. · Source: kinsta.com

    To find which plugin caused a conflict without taking a client site down, use the Health Check plugin’s troubleshooting mode. It disables plugins and switches to a default theme for your logged-in session only, so visitors keep seeing the normal site while you turn things back on one at a time.

    Standardize the stack before you automate it

    A dashboard makes a stable portfolio cheaper to run. It doesn’t make an unstable one stable. When someone on r/Wordpress described 20-plus sites breaking every day, the replies were nearly unanimous: fix the hosting, the plugins and the access problems first, then add a dashboard.

    The biggest factor is how many different plugins and themes your sites run. Every extra plugin that appears on only one site makes the next bulk update harder to predict. The habits that reduce failures are simple:

    • Keep a short approved plugin list for new builds, and build new sites from a clean copy of a good one.
    • Remove abandoned plugins, and replace ones the client picked that no longer get updates.
    • Put sites on as few hosts and PHP versions as you can.
    • Keep a current list of every plugin and version on each site. Listing plugins with wp plugin list exports one per site in seconds.
    • Have SSH or file access to every site, so you can rename a broken plugin’s folder when the dashboard can’t reach the site.

    Teams with developers go further: version control, staging and automated tests that run before anything reaches production. That’s worth it with hundreds of sites. With fifteen, a disciplined manual routine is usually enough.

    What a management dashboard does not cover

    Dashboards do maintenance: updates, backups, uptime and security. Several other jobs come with running a portfolio, and they need their own plan.

    Content and small changes. The phone number on three sites, the campaign page and the broken form from the opening never show up in an update queue. They arrive as requests, they differ for each site because each site’s header and footer are built differently, and they take up the delivery time a care plan was priced to protect. Changing six words in a footer shouldn’t need a ticket, a developer and a deployment window. On most agency teams, it still does.

    Store reporting. A maintenance dashboard won’t combine orders, revenue or inventory from several WooCommerce stores. Operators who want one sales view across shops use a separate WooCommerce reporting tool for that.

    Search. Google’s spam policies treat sets of near-identical sites, or city-targeted sites that funnel visitors to one destination, as doorway abuse. If you build regional sites from one template, each one needs content of its own.

    Accessibility. A shared template spreads its flaws to every site built from it. Fix contrast, focus states and form labels in the template, then check each site too, because the content on each one adds its own problems.

    Our explainer on what maintenance packages actually cover helps draw this line when you scope a client plan.

    How the work changes when an agent handles the exceptions

    The routine part of multi-site maintenance is already automated. What’s left is the work that lands on a person: the one site out of forty that broke, the form that stopped sending, the wording change that differs on every site. That’s the work SiteSelf is for. It joins your stack and doesn’t replace your dashboard or your host.

    Example request: “After last night’s plugin updates, the contact form on harbourdental.com stopped sending notification emails. Find out why, fix it, and tell me what changed.”

    Here’s what the agent would do. It reads the site’s error log and the form plugin’s settings. It compares what changed with the update, then applies the fix: a setting, a conflicting plugin, or a mail configuration that the update reset. Before the change, it says what is about to change and whether that can be undone. Afterwards it fetches the contact page, confirms the page loads with the form in place, and reports in chat what it changed and what it checked. The work is recorded, so the next person who opens that client’s thread can see what happened.

    For access, settings and content work goes through the SiteSelf Connector plugin from the WordPress.org directory. Reading logs, editing files and reverting a plugin needs hosting (SSH) access to that site.

    There are honest limits. The check is a fetch of the changed page and a plain-language report. It’s not a test submission from a real inbox and not a full device test, so send yourself one test message. Pages owned by Elementor, Divi or Beaver Builder are refused when the work starts, with the reason given. Nothing runs on a schedule and nothing watches the sites. The agent works when someone asks, so your dashboard keeps handling the routine updates. The page on client site work for agencies shows how this fits a retainer, and pricing explains how credits work.

    Frequently asked questions

    Can I manage multiple WordPress sites without Multisite?

    Yes, and for independent sites you usually should. Keep each site as its own install and connect them to a dashboard or your host’s multi-site panel. You get central updates and backups without one network’s problems reaching every client.

    How many sites justify Multisite?

    No number settles it. The question is whether the sites belong together: the same owner, the same design, the same plugins and the same admins. Two closely related sites can suit a network. Twenty unrelated client sites usually don’t.

    Can I run several WordPress sites on one hosting account?

    Yes. Most hosting plans allow several separate installs. The limit is server resources. Once one busy site slows the others down, move the heaviest sites out one at a time rather than migrating everything at once.

    Should I let the dashboard auto-update plugins?

    Auto-updates are reasonable for low-risk plugins on simple sites, as long as you have a backup you have tested restoring. For payment, membership, caching and page builder plugins, update them yourself, check the site afterwards, and take care with stores.

    Can one dashboard manage several WooCommerce stores?

    For maintenance, yes: updates, backups and uptime work the same as for any WordPress site. For business data such as combined orders, revenue and stock, no. You need a WooCommerce reporting tool, or a sync extension if the stores have to share products or orders.

    Is it safe to copy the same page to several sites?

    A shared policy or legal page is fine. Whole sites that differ only in a city name or a small wording change risk falling under Google’s doorway rules. Give each site content its visitors can’t get from the others.

  • What website maintenance packages actually cover

    Key takeaways

    • Codeable and Pantheon both put WordPress maintenance pricing anywhere from $30 to more than $5,000 a month. Two quotes only compare when their scope matches line by line.
    • Updates are the main task in every package and the most common thing that breaks a site. The process that holds up is a fresh backup, staging for risky sites, a fixed update order, a test of forms and checkout, and a way to roll back.
    • WooCommerce’s own update guide says to back up the database as well as wp-content, run any database update, and test cart, checkout, payments and order emails before you reopen the store.
    • Scanning isn’t cleanup and managed hosting isn’t maintenance. Pantheon notes that cheaper plans often only scan or alert and charge extra for cleanup and break/fix work.
    • Before you sign, get four things in writing: where backups are stored, when a restore was last tested, who pays when the provider’s own update breaks the site, and what ‘minor edit’ means.

    Two quotes for “WordPress maintenance” can differ by a factor of ten, and both can be honest. Codeable and Pantheon each put the range at $30 to more than $5,000 a month. The word covers everything from a plugin that runs updates overnight to a developer who tests every change on a copy of your site and answers the phone when checkout stops working.

    So the useful question isn’t what a package costs. It’s what work happens, how it gets checked, and who is responsible when something breaks. Get those three answers and you can compare any two quotes.

    Why there is no standard maintenance package

    No official definition of a maintenance package exists. WordPress.org’s site maintenance documentation lists tasks: update WordPress, check for dead links, delete spam, back up the site, keep a maintenance calendar. It never defines a product. Providers then mix those tasks with hosting, plugin licences, edit time, testing and incident response in whatever combination suits them.

    That’s why “care plan”, “maintenance plan” and “retainer” mean roughly the same thing, and why plans with the same name cost wildly different amounts. A WordPress site needs upkeep whoever does it. Our look at WordPress for business websites covers why that cost often goes unbudgeted at launch. The package is just one way of buying that upkeep.

    What the common line items mean in practice

    Most packages list the same five or six items. Each one has a cheap version and a version that actually protects you, and the proposal rarely says which you’re getting.

    Line itemMinimal versionVersion that protects you
    UpdatesAuto-updates run blind on a scheduleBackup first, staging for risky updates, a fixed order, key pages and forms tested afterwards
    BackupsA nightly job on the same serverDatabase and files, stored off-site, with restores actually tested
    SecurityA scanner that sends alertsScanning plus cleanup included, entry point closed, credentials rotated
    Uptime monitoringA ping that confirms the homepage loadsChecks on the things that make money: forms, checkout, logins
    ReportsA list of plugins updatedWhat changed, what was checked, what failed, what is still open
    Edits and support“Unlimited minor edits”A stated allowance, a definition of “minor”, an hourly rate for the rest

    Read a proposal against the right-hand column. “Updates included” tells you nothing. “Updates tested on agreed pages, with a backup point and a change record” tells you what you’re buying.

    Why updates are where a package earns its fee

    Updates are the core routine task, and they’re also the usual reason a site breaks. Plugins, themes, core and PHP change all the time, and a mismatch shows up as a white screen or “There has been a critical error on this website.” WordPress’s Advanced Administration Handbook lists plugin compatibility problems as a cause of exactly that. WooCommerce’s self-service guide names outdated software and plugin or theme conflicts among the common causes of store problems.

    The process that works is the same across WordPress’s docs, WooCommerce’s docs and practitioners who run dozens of sites:

    1. Take a fresh backup of files and database, stored off the server.
    2. Run updates on staging first for any site where a break costs money: stores, membership sites, builder-heavy sites.
    3. Update in a consistent order, one at a time, and let each finish before starting the next.
    4. Test what matters. A site that loads isn’t the same as a site that works. Submit the contact form and run a checkout.
    5. Keep the rollback ready, and know before you start what rolling back would lose.

    When a step fails, the cause is usually a single plugin. Our guide to fixing plugins that stop working walks through isolating it.

    WordPress Updates screen showing pending plugin updates in a website maintenance routine
    A queue of pending core and plugin updates in the WordPress dashboard highlights the critical maintenance work required to apply security patches without breaking live site functionality. · Source: crocoblock.com

    Two misunderstandings cause most of the damage here. First, auto-updates aren’t a maintenance plan. Kinsta’s documentation says its automatic updates take a backup beforehand and may restore it after detecting a change, and that this rollback can lose changes made during the update window. On a store, those changes are orders. Automation helps, but someone still has to notice what it did.

    Second, removing the maintenance message doesn’t mean the update worked. When an update is interrupted, WordPress can leave a .maintenance file in the site root, and every visitor sees “Briefly unavailable for scheduled maintenance. Please check back in a minute.” The handbook’s fix is to delete that file over FTP. But the plugin or core files may still be half-updated afterwards, so confirm the update finished or run it again.

    WooCommerce stores need a stricter routine

    WooCommerce’s guide to updating says a monthly cadence suits most stores, with security fixes or broken functionality handled sooner. Its procedure asks for more than a brochure site needs:

    • Back up the database as well as wp-content. A files-only backup has no orders in it.
    • Stage the full set of updates together: WooCommerce, extensions, payment gateways, theme.
    • Let each update finish, then run the database update if WooCommerce asks for one.
    • Watch Scheduled Actions for stuck or failing background tasks.
    • Test products, cart, checkout, payments, shipping, taxes and order emails before reopening checkout.

    If a store is on a package that just presses “update all”, the package isn’t doing the store’s job.

    WooCommerce database update notice in the WordPress admin during store maintenance
    An admin banner requiring an explicit database update illustrates why WooCommerce maintenance demands an extra step beyond standard plugin upgrades. · Source: woocommerce.com

    Why a backup only counts if it restores

    A backup job that reports success proves that a file was written. It doesn’t prove you can get the site back. WordPress.org recommends keeping a backup on the hosted site and a separate copy elsewhere, because a backup on the same server goes down with the server or the hosting account.

    There are four failures to ask about:

    • Same-server storage. The host fails or the account is suspended, and the backups go with it.
    • Never-tested restores. WP Umbrella suggests a restore test to staging about once a quarter for revenue sites, roughly 20 minutes each. That’s a suggested effort, not a measured one.
    • Restoring over new orders. Rolling a store back to last night wipes out today’s sales.
    • Restoring an infected copy. A backup taken after a compromise brings the attacker’s code back.

    Our explainer on what a backup plugin covers goes through where each popular approach falls short.

    Why security scanning is not malware removal

    Pantheon’s guide to maintenance plans says lower-cost plans often scan or alert and bill cleanup separately. You find out which kind you have on the day of a hack, at emergency rates.

    A real cleanup is a short incident response job. Ben Ryan, who sells WordPress maintenance, lays it out in eight steps: isolate, back up, scan, clean the files, clean the database, rotate every credential, update everything, then verify and harden. He notes that most do-it-yourself cleanups find the malware but skip the last three steps, and the site gets reinfected within days. Our guide to malware removal that does not come back covers that sequence.

    The question to put to a provider is simple: is cleanup included, or does it count as emergency work at an hourly rate?

    Managed hosting covers the platform, not your site

    Good managed hosts handle the server, often core updates and backups, and sometimes automatic plugin updates. Pantheon draws the line clearly: plugin conflicts, application testing, edits and break/fix work usually fall outside hosting. Those stay with you or with whoever maintains the site.

    For a simple brochure site with few plugins, good hosting plus a monthly check of your own may be enough. Once the site has integrations, custom code or a checkout, someone has to own the application layer.

    How to read a price without a going rate

    No representative pricing survey exists for small businesses, so any “average” you read is a vendor’s estimate. WP Umbrella, which sells maintenance tooling, puts productized care plans at $50 to $150 per site per month, and premium or developer-led service at $240 to $1,000 or more. Those are bands, not benchmarks.

    Three things move a fair price more than the plan’s name:

    • Risk. A brochure site that’s offline for an afternoon costs little. A store that’s offline costs orders. Staging, human testing and fast response all cost money, and they’re what the higher tiers pay for.
    • Human time included. Edit allowances in community examples run from 15 minutes to two hours a month. Check what happens when you go over.
    • What sits outside the fee. Cleanup, repair after a bad update, speed projects, new pages, licences. In MainWP’s 2023 Web Care Survey, 65% of consultants said they include software or plugin licences in their plans, so some quotes bundle licences and others don’t. Codeable’s pricing guide makes the same point: compare the costs outside the fee, not the headline number.

    The same MainWP survey found three tiers to be the most common structure. It had only about 64 responses, so treat that as a pattern among providers, not a rule.

    Questions to ask before you sign

    Ask for answers in writing. Better still, ask for a sample monthly report.

    • Are updates tested on staging before production? For which sites?
    • Which pages and flows do you check after updates: forms, checkout, logins?
    • How often are backups taken, where are they stored, and when was a restore last tested?
    • Does the plan include malware cleanup, or only scanning?
    • If your update breaks the site, who pays for the repair, and does it come out of my support hours?
    • What counts as a “minor edit”, how many are included, and what is the hourly rate beyond that?
    • What response time do you commit to for an outage?
    • Who owns the domain, the hosting account and the backups if we part ways?

    Treat “zero downtime”, “fully managed” and “unlimited” as red flags unless the proposal says what work sits behind them. The same goes for any plan that updates a store with no staging.

    How the work changes when an agent runs the updates

    Most of what a package sells is small, repeatable work. The process around that work is where the cost goes: a ticket, a wait, someone reading the request, a report you can’t quite follow. Updating three plugins on a contact-form site shouldn’t need a support queue and a monthly invoice line you can’t verify.

    SiteSelf takes a different approach. You tell the agent what you need in chat, it does the work on the live site, checks the result, and reports what changed. Here is what an update request looks like.

    Example request: “Run the pending plugin updates on the shop. Do the payment gateway on its own, after the others. Tell me if WooCommerce wants a database update, and tell me what you changed and what you checked on the shop and checkout pages.”

    The agent lists what’s out of date and reads the changelogs for anything that looks like a major release. Before it changes anything, it says what it’s about to change and whether that can be undone. It applies the updates in the order you asked for, reports whether the WooCommerce database update is pending, then fetches the shop, cart and checkout pages and tells you in plain language what it found. What it did is recorded. Our page on WordPress plugin updates handled in chat covers this work in more detail.

    Access matters. Content and settings work goes through the SiteSelf Connector plugin from the WordPress.org directory. Updating plugin files and fixing anything that breaks needs hosting (SSH) access.

    There are also limits:

    • The check is a fetch of the changed page, not a full device test. It shows that checkout loads. It doesn’t prove a payment goes through, so placing a test order is still your job.
    • Nothing runs unattended. There’s no monitoring and no scheduled update cycle. Work happens when you ask.
    • Pages owned by Elementor, Divi or Beaver Builder are refused at the moment of work, with the reason.
    • Your backup plugin or your host’s restore points are still your safety net.

    That makes it a different trade from a package. You give up a provider who watches the calendar for you. In return, each change is done when you ask, explained before it happens and reported after. Pricing is credit-based, and the details are on the pricing page.

    Frequently asked questions

    Is a care plan different from a maintenance plan?

    Not in any consistent way. Providers use “care plan”, “maintenance plan” and “retainer” for the same kind of recurring arrangement. Compare the listed tasks, not the name.

    Can I maintain a WordPress site myself?

    Yes, especially a simple one. WP Umbrella estimates a manual update session at 15 to 30 minutes per site, once or twice a month. The routine part isn’t the hard part. The hard parts are tracking down a plugin conflict, restoring safely and cleaning up after a hack, and those are the moments when a package or a specialist pays for itself.

    Are automatic updates enough on their own?

    Not for a site that makes money. Automatic updates don’t test your forms or checkout, and rollbacks can lose data. Kinsta’s docs say its rollback can lose changes made during the update window. If you rely on auto-updates, someone still needs to check the site afterwards.

    What does “unlimited edits” usually mean?

    Usually small text and image swaps. Pantheon notes that new pages, content writing and functionality changes are typically excluded. Ask for the per-request limit and the hourly rate for anything bigger, in writing.

    Who pays if the provider’s update breaks my site?

    It depends on the contract, and many contracts don’t say. Pantheon flags that some plans bill troubleshooting of update-caused problems separately. Settle it before you sign, along with whether that repair counts against your support hours.

    How often should a WordPress site be updated?

    WooCommerce suggests checking monthly for most stores, and acting sooner for security fixes or broken functionality. Practitioners range from daily to monthly. The common ground is to apply security patches quickly and test major feature releases on staging first.

    WordPress briefly unavailable for scheduled maintenance message after a failed update
    WordPress displays this standard maintenance message during updates, but manually clearing the lock file does not verify that the process completed successfully. · Source: www.wpzoom.com