SiteSelf

Blog

  • What a WordPress customisable theme really means

    Key takeaways

    • Block themes are edited in Appearance > Editor. WordPress.org’s documentation says the Site Editor is only available with a block theme, so a missing Customize menu is often expected and not a fault.
    • Small styling fixes go in Styles or Additional CSS. Code goes in a child theme. Edits to parent theme files are lost when the theme updates.
    • Additional CSS belongs to the active theme and does not move with you to a new theme. A child theme created later does not take your existing settings with it.
    • When a change does not appear, check in this order: was it saved or published, is a cache serving the old version, and is the CSS loading and winning.
    • In WordPress’s 2023 annual survey, 45% of respondents said the Site Editor met their needs. A theme’s settings can run out, and you should know where that point is before you buy.

    You can customise every WordPress theme. The question is how far you can get without writing code, and whether your change will survive the next update. Most frustration with “customisable” themes comes from mixing up those two things.

    This explainer covers what the word means in practice, how the two WordPress editing models differ, which layer each kind of change belongs in, and how to tell when a theme’s options have run out. If you are still choosing a base, our guide to layout and design on WordPress covers the structural side.

    “Customisable” means options to an owner and code to a developer

    For a developer who writes PHP, CSS and JavaScript, every theme is fully customisable. For an owner who doesn’t, “fully customisable” means the theme has a lot of built-in settings. Those are two very different promises, and theme marketing usually leaves you to work out which one you are getting.

    The gap appears with very specific changes: the colour of the mobile menu, the spacing on one section, the font on a WooCommerce product page. A theme can have hundreds of settings and still not have the one you need. A WordPress.org support thread called “Editing a custom theme” shows how this goes. Someone took over an agency-built site and was installing plugins to make simple changes like padding, because the theme gave them no setting for it.

    When you judge a theme, ignore how many options it has. Ask whether it lets you make the changes you will actually make, in a place that survives an update.

    Which editor you have decides where the settings are

    WordPress has two editing models. Most confusion about customisation starts when a tutorial describes one model and your site uses the other.

    • Block themes are edited at Appearance > Editor, which opens the Site Editor. Styles (colours, typography, layout), templates and template parts such as the header and footer are all there. WordPress.org’s documentation says the Site Editor is only available when a block theme is active.
    • Classic themes use Appearance > Customize, the Customizer, if the theme supports it. Many classic themes also add their own options page.

    To check which one you have, open Appearance in the dashboard. If you see Editor, you have a block theme. If you see Customize, you have a classic theme. Some setups show both, either a hybrid theme or a plugin that brings the Customizer back. If a guide sends you to Appearance > Customize and that menu isn’t there, nothing is broken. Your theme puts those controls in the Site Editor.

    Page builders such as Elementor and Divi add a third layer. When a page builder owns the header or a page, change it in the builder. If you change it in the theme instead, the builder can override your change.

    Put each change in the layer that survives updates

    Where you make a change matters more than which theme you have. WordPress’s Theme Handbook says a child theme lets you modify a theme without editing that theme’s own code. That matters because an update replaces the parent theme’s files, along with any edits you made to them.

    The changeWhere it belongsWhat to watch
    Brand colours, fonts, site-wide spacingStyles in the Site Editor, or the theme’s Customizer optionsOne global colour can change links, buttons and notices across the site
    One spacing fix, a hover state, a narrow overrideAdditional CSS (on block themes, CSS lives under Styles)It is tied to the active theme and stays behind if you switch
    Template markup, PHP, new functionsA child themeParent updates can still rename classes your code depends on
    A redesign the theme fights at every stepA different base themeContent carries over. Layout and theme-specific settings don’t

    There are two catches. First, creating a child theme after you have customised a parent does not automatically copy those customisations across. Settings stored against the parent theme may have to be recreated in the child. Second, the advice in that WordPress.org thread differs for small and large changes. For small changes, find the element with your browser’s inspector and save an override in Additional CSS. For large changes, choose a theme that is already close to what you want. A bare starter theme has almost no styling, so you would be rebuilding the layout from scratch.

    For a full walkthrough of each layer, see theme customization that survives updates.

    Why a saved change often doesn’t show up

    The most common complaint about theme customisation is a change that does nothing. There’s no error message. The page just looks the same. Check these causes in order, starting with the cheapest.

    1. It was previewed, not published

    WordPress.org’s Customizer documentation explains that you can try changes without publishing them. Nothing goes live until you click Publish. The Site Editor has its own Save button. When you live-preview a theme you haven’t activated yet, nothing is kept until you activate and publish it.

    2. A cache is serving the old page

    A site can have caches in several layers: the browser, a caching plugin or the theme’s own optimisation, the host’s server cache, and a CDN. Clearing one layer proves nothing about the others. Open the page in a private window, purge each layer, and regenerate any combined or minified CSS your optimisation plugin creates. Purging won’t fix a change that was never saved, though.

    3. The CSS isn’t loading, or something else beats it

    Right-click the element and choose Inspect. If your rule appears with a line through it, a more specific rule is winning. If it doesn’t appear at all, check the Network tab to see whether your stylesheet loads. In a child theme, the child stylesheet has to load after the parent’s, or the parent’s rules win. Our article on why a font change is not showing walks through this inspection step by step.

    If the site breaks after a change instead of staying the same, you probably have a conflict, not a styling problem. Learn WordPress’s lesson on plugin and theme conflicts recommends this method: back up, work on a staging copy, deactivate plugins and reactivate them one at a time, and use error logs to find the cause. Our guide to plugins that stop working covers the same isolation process.

    What to check before you choose a theme

    A demo shows you what the theme can look like. It doesn’t show you what editing it will feel like six months after launch. Test these things instead.

    • The editing model. A block theme gives you visual control over templates. A classic theme gives you whatever its panels expose. In WordPress’s 2023 annual survey, 45% of respondents said the Site Editor met their needs, so try it before committing.
    • The changes you’ll make most. Open the theme’s documentation and check that the header, footer, mobile menu, content width and archive layout can be edited without code.
    • Your plugins. If you run WooCommerce, a form plugin or a builder, build a real product page or form on a staging copy. A polished demo doesn’t prove compatibility.
    • Maintenance. Look at the update history and the support channel. A plainer theme with clear templates is often cheaper to own than one packed with features.
    • Lock-in. If your layout lives in a page builder, it goes with the builder. Builders are fast to work in. The cost shows up when you want to leave.

    Your site will also never look exactly like the demo, because the demo uses its own images and copy. Import starter content onto a fresh install or a staging copy, not a live site. Installation problems are covered in installing a theme without breaking it.

    Design changes can break what you can’t see

    A change can look right and still make the site harder to use. W3C’s WCAG quick reference sets a minimum contrast ratio of 4.5:1 for normal-sized text. A darker brand colour on a button, or light grey body text, can fall below it. A common CSS reset removes focus outlines, and then keyboard users can’t see where they are on the page. After any colour or navigation change, check contrast, tab through the menu and forms, and make sure links still stand out by more than colour alone.

    WooCommerce stores have one more risk. If your theme overrides WooCommerce templates, WooCommerce’s developer docs explain that WooCommerce sometimes updates its default templates in new releases, and your theme’s copies don’t update with them. WooCommerce’s System Status report, at WooCommerce > Status, lists outdated overrides. To fix one, back up the override, copy in the current template, reapply your changes and test. If you replace the file without reapplying your changes, you lose your customisation.

    WooCommerce System Status listing outdated theme template overrides
    The WooCommerce System Status report flags template overrides that lag behind the active core version, exposing potential hidden display conflicts. · Source: totalwptheme.com

    When the theme’s options run out

    Sooner or later you will want a change that no setting covers. Your options, from simplest to biggest:

    1. Find the element with the browser inspector and add a narrowly targeted rule in Additional CSS.
    2. Put template or PHP changes in a child theme, so the parent can keep updating.
    3. If almost every change is a fight, move to a theme that is closer to what you want, and test the move on staging first.
    4. Hire someone, with a written scope and agreed milestones. Editing a template is a much smaller job than building custom functionality, so describe exactly which one you need.

    If you would rather describe the change than track down the selector, SiteSelf takes requests like this in chat and makes them on your existing theme. Our page on having design changes made for you covers what that includes.

    Whichever route you take, keep a short note of what changed and where: a setting, a CSS rule or a child-theme file. After the next theme or plugin update, that note tells you exactly what to check. Our guide to updating a theme without losing work covers that check.

    Frequently asked questions

    Why can’t I find Appearance > Customize?

    You probably have a block theme. Block themes put their design controls in the Site Editor at Appearance > Editor, under Styles, Templates and Patterns. Nothing is broken.

    What is the most customisable WordPress theme?

    No theme is the most customisable for everyone. It depends on which controls you need and whether you can write CSS. Make a list of the five changes you expect to make most often, and test each candidate theme against that list.

    Can I customise a free theme?

    Yes. Free themes include the Site Editor or Customizer controls, and you can add Additional CSS or a child theme to any of them. Many free themes keep some settings for a paid pro version, so check the documentation to see which options are free.

    Will changing my theme delete my content?

    No. Posts, pages and media stay in the database. Theme-specific settings, Additional CSS, widget placement, menu locations and theme shortcodes may not carry over, so try the switch on a staging copy first.

    Do I need a child theme just to change a colour?

    No. Use Styles or Additional CSS for colours, fonts and spacing. You need a child theme once you are editing template files or adding PHP.

  • What is a slug in WordPress and when to change it

    Key takeaways

    • The slug is one segment of the URL. The permalink is the whole address, and Settings > Permalinks sets the pattern for the whole site.
    • Retitling a published post or an existing WooCommerce product leaves its slug as it was, so the URL stays stable until you change it yourself.
    • A -2 on the end of a slug means something else already has that slug, often an item in Trash or a Media file. You fix it in the dashboard.
    • Saving Settings > Permalinks refreshes rewrite rules. It does not redirect an old URL and it does not fix a real name collision.
    • Slugs help readers more than rankings. Google asks for readable, hyphenated URLs, but leaving a working URL alone usually beats a cleaner one.

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

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

    What is a slug in WordPress, exactly?

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

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

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

    How is a slug different from a permalink?

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

    Permalink structureExample URLWhere the slug appears
    Plainexample.com/?p=123Not in the URL at all
    Post nameexample.com/first-post/The whole path
    Day and nameexample.com/2026/10/15/first-post/After the date
    Customexample.com/blog/first-post/After a fixed base

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

    WordPress permalink settings screen with structure options for the slug
    The WordPress permalink settings determine the global URL architecture, controlling exactly where each post slug appears across the entire site. · Source: www.boldgrid.com

    How does WordPress create a slug?

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

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

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

    Where do you find and edit a slug?

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

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

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

    Editing a WordPress slug in the block editor settings sidebar
    Selecting the Page tab in the sidebar reveals the permalink panel where you can inspect and refine your URL slug prior to publishing. · Source: taylorhieber.co

    Why did WordPress add -2 to my slug?

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

    Check these places in order:

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

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

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

    What happens when you change a published slug?

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

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

    To change a live slug safely:

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

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

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

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

    Do slugs help SEO?

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

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

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

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

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

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

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

    WooCommerce product permalinks settings with product and category slug bases
    Configuring distinct URL structures for product categories and individual products prevents base collisions that trigger unexpected 404 errors. · Source: premmerce.com

    Frequently asked questions

    Can a post and a page have the same slug?

    The text can match when the full URLs differ, for example when posts use a date-based structure. Under the Post name structure both would want the same address, so WordPress adds a number to one of them. Pages and custom post types that share a path can also collide and return 404s.

    Is there a maximum slug length?

    No official limit is documented for everyday use, and we would not trust anecdotal numbers. Long slugs are hard to read and share, so keep yours to the few words that describe the page.

    Which permalink structure should I choose?

    Most practitioners recommend Post name, set before you publish real content. Avoid Plain, which gives URLs like ?p=123. If the site already has traffic, keep the structure you have unless you have a redirect plan for every URL.

    Can I change an author slug?

    Not from the standard profile screen. The author slug is stored separately from the display name, and changing it needs a plugin or code. Changing it moves the author archive URL, so redirect the old one.

    Does a descriptive slug help accessibility?

    Not directly. WCAG’s link-purpose guidance is about link text, not URL format. A clear slug won’t fix a “click here” link, and accessible link text doesn’t need any particular slug.

    Should I remove the /product-category/ base in WooCommerce?

    Only if you understand the tradeoff. WooCommerce’s permalink docs say the product and category bases must not conflict, and removing the base raises the risk of collisions in large catalogs. If you shorten it, redirect the old category URLs.

  • How to optimize pictures in WordPress

    Key takeaways

    • Resize before you compress. Compressing a 5,000 px photo shown in a 600 px slot still leaves WordPress processing and generating thumbnails from the oversized original.
    • Generating WebP or AVIF is not the same as serving it. CSS background images, page builders and host rules can leave visitors on JPEG while the plugin reports success.
    • Never lazy-load the hero image. Google advises against lazy-loading content visible on first load, and WordPress.org reported its 6.3 loading changes made pages with a hero image up to 21% faster.
    • Bulk optimization failures usually come from server limits, such as PHP memory, a missing Imagick or GD library, or a firewall, rather than from plugin settings.
    • Blurry WooCommerce product images usually mean the theme asks for sizes your images do not match. Use sources of at least 800 x 800 px and regenerate thumbnails after any change.

    The median WordPress page loads about 725 KB of images on mobile, according to the HTTP Archive’s 2024 Web Almanac. On 68% of mobile pages, the largest thing a visitor sees first is an image. So when a page feels slow, pictures are the first place to look. They are rarely the only cause.

    Optimizing pictures comes down to three jobs. Upload images sized and compressed for where they display. Serve responsive and modern-format versions that the browser actually receives. Don’t delay the image people see first. Do them in that order, because each one depends on the one before it. And if images turn out not to be the bottleneck, remember that a slow WordPress site usually has more than one cause.

    What do you need before you start?

    You need an administrator login, permission to install a plugin, and a browser with developer tools (Chrome or Firefox). If you have to change server rules for WebP delivery, you also need your host’s control panel or their support team. Take a backup first. Any bulk operation that rewrites files should be undoable.

    Next, measure two things for the page you care about. Find the width the theme actually renders each image at: right-click the image, choose Inspect, and hover the <img> element to see its displayed size. Then open the image’s details in the Media Library and check the uploaded dimensions and file size. If an image displays at 700 px wide and the upload is 4,000 px, you have found the biggest win before touching any plugin.

    How to optimize pictures in WordPress, step by step

    1. Resize each image to the size the theme displays.
    2. Compress it, then look at the result.
    3. Leave WordPress’s responsive image markup intact.
    4. Pick one way to serve WebP or AVIF and confirm it works on your host.
    5. Load the hero image eagerly and lazy-load only what sits below the fold.
    6. Clear every cache and check the live page.

    1. Resize to the size the theme actually displays

    Sizing matters more than anything else. A phone photo uploaded straight to the Media Library is often several megabytes and thousands of pixels wide. Compression shrinks the bytes, but the pixels are still there. WordPress still has to process that original and build every thumbnail size from it.

    Aim for the largest width the image ever renders, or about twice that if you want sharp results on high-density screens. Practitioners on Reddit describe taking a 3 MB, 2,500 px product photo down to about 800 px and roughly 100 KB with no visible loss. For a full-width hero, around 2,000 px is a common ceiling.

    You will see 2,560 px mentioned a lot. That isn’t a recommendation. It’s the point where WordPress creates a “-scaled” copy of a large upload, and it’s the “suggested maximum” in WordPress’s upload error. Treat it as the point where WordPress starts scaling uploads down, not as a size to aim for.

    You can resize before upload with a desktop editor or a free browser tool such as Squoosh. You can also use a plugin that caps uploads at a maximum width and can resize images already in the library. If staff or clients upload directly, a cap is more reliable than training.

    2. Compress, then look at the result

    The WordPress.org documentation on image size and quality treats quality and file size as a tradeoff, and it is one. Lossy compression saves the most and can cost detail. Lossless compression keeps every pixel and saves less. Photos usually take lossy compression well. Screenshots with text, logos and product close-ups often don’t.

    WordPress.org support forums have threads about images coming out blurry or with dull, muted colours after compression. The usual fix is to lower the compression level and keep the originals so you can reprocess. Before you run a whole library, compress a handful of representative images and look at them at full size. Check a face, a fabric texture, a gradient and a logo.

    3. Leave srcset and sizes alone

    Since version 4.4, WordPress adds srcset and sizes attributes to the image markup it generates. srcset lists the available widths. sizes tells the browser how wide the image will display, so a phone downloads a phone-sized file. WordPress’s Responsive Images handbook notes that core does not add or change these attributes if the markup already has them.

    The risk is custom markup. A theme, a builder module or a hand-written <img> tag can leave them out. If mobile visitors are downloading desktop-sized files, inspect the rendered HTML and check whether those attributes are there.

    4. Pick one way to serve WebP or AVIF

    This is where most image work quietly fails. Converting a JPEG to WebP creates a second file. Serving it means the page, or the server, has to hand that file to the browser instead of the original. Imagify’s documentation treats these as two separate steps, and so should you.

    Plugins usually offer two delivery methods. The <picture> method rewrites your HTML, replacing <img> with <picture>. Imagify warns that some themes and plugins aren’t fully compatible with it. The rewrite-rules method changes server configuration and leaves the HTML alone. Imagify recommends rewrite rules unless the site uses a CDN or Cloudflare.

    Your host decides which of these can work. WP Engine’s support documentation says .htaccess methods don’t work on its platform. It uses Cloudflare Polish through its edge network, or an NGINX rule from its support team. Copy Apache instructions onto a host like that and nothing errors. Nothing changes either. Read your host’s WebP page before adding any rules.

    Some images can’t be swapped at all by a normal plugin. In one WordPress.org thread, a site using The7 theme had AVIF files generated for the whole homepage, yet only one image loaded as AVIF while the rest stayed JPEG. ShortPixel support explained that CSS background images, images loaded by JavaScript, page builders and a second lazy-load system can each block normal delivery.

    Use one image optimizer. Two optimizers, or an optimizer plus a host or CDN feature doing the same job, will fight over rewrites and give you false failures. Adoption is still low anyway: the 2024 Web Almanac counted WebP at 12% and AVIF at 1% of mobile image requests. WebP is the safer default. AVIF makes smaller files but takes more server effort to encode, and your server’s image library has to support it.

    5. Load the hero image first and lazy-load the rest

    Google’s Search Central guidance says not to lazy-load content that is likely to be visible right away. The hero image is exactly that content. Lazy-loading it makes the browser find it late, which delays Largest Contentful Paint. Your PageSpeed score can still go up while the page gets slower for real visitors.

    WordPress core treats loading="lazy" and fetchpriority="high" as conflicting values. Since WordPress 6.3, core tries to identify the likely LCP image itself and give it priority. WordPress.org reported that this made pages with a hero image load up to 21% faster. Theme and plugin markup can still override it, so check. A correctly loaded hero looks like this:

    <img src="/wp-content/uploads/hero-1600x900.webp"
     width="1600" height="900"
     fetchpriority="high"
     alt="Bakery counter with fresh loaves">

    There is no loading="lazy", and the width and height are explicit so the browser reserves the space and the layout doesn’t jump. Everything below the fold, such as later gallery items, related-post thumbnails and footer logos, should keep lazy loading. Run one lazy-load system only.

    6. Clear every cache and check the live page

    Settings screens report what a plugin did. Only the live page shows what a visitor gets. Clear the plugin cache, the server cache, the CDN cache and your browser cache. Then open the page in a private window and look at the Network panel with the Img filter on.

    Chrome DevTools Network panel showing WordPress images served as WebP
    Inspecting the Type column in the browser Network panel confirms the exact file format delivered to visitors alongside transferred file sizes. · Source: developer.chrome.com

    What does a correctly optimized page look like?

    In the Network panel, the Type column shows webp or avif for your content images. Transferred sizes are in the tens or low hundreds of kilobytes, not megabytes. On a phone-width viewport, the file the browser picked is close to the displayed width. In the Elements panel, the hero image has no loading="lazy" attribute. And at full size, the images still look like the photos you took.

    If the page is still slow after all of that, images were not the bottleneck. Look at scripts, the theme, caching and hosting next.

    What to do when it did not work

    WebP files exist but the page still serves JPEG

    Go through the causes in order. Is the image a CSS background? Is a page builder outputting its own markup? Is a second plugin also lazy-loading or rewriting images? Is your host one that ignores .htaccess? Is a CDN serving a cached copy? Fix one cause, clear caches, and check the Network panel again.

    Images broke after you turned on next-gen delivery

    Imagify’s troubleshooting steps work as a general test. Turn off the next-gen display setting, then clear the plugin, browser and CDN caches. If the images come back, delivery caused the problem. Switch methods on purpose: rewrite rules when there is no CDN or Cloudflare, <picture> when there is.

    Bulk optimization stalls or throws errors

    Running it again rarely helps, because the cause is usually the server. In one ShortPixel review on WordPress.org, a bulk run took more than 36 hours and ended with 197 errors. The causes were a CloudLinux memory limit killing PHP processes and a firewall that needed the service’s IP addresses allowed. Once the host raised the limit, the run finished. The site owner still saw little speed gain, which is a reminder to measure before assuming images are the problem.

    Check the PHP memory limit, whether Imagick or GD is installed, and whether the uploads folder is writable. Then ask your host to read the error logs. Credit-based services often count every generated thumbnail size, not just the original, so exclude sizes your theme never uses before you start a large run.

    Uploads fail with “The server cannot process the image”

    WordPress shows this message, which ends with “Suggested maximum size is 2560 pixels”, when the server runs out of resources while processing an upload. Resize the file and try again, then fix the underlying limit. Our article on image upload and Imagick errors covers the server side.

    WordPress image upload error suggesting a maximum size of 2560 pixels
    WordPress attributes the processing failure directly to exhausted server resources, recommending reduced image dimensions as an immediate workaround. · Source: webtrainingwheels.com

    Why WooCommerce product images look blurry

    WooCommerce’s documentation says blurry product images usually come from theme styling that asks for dimensions your uploaded images don’t match. It recommends source images of at least 800 x 800 px for most themes, and image width settings that match or exceed what the theme renders. Regenerate thumbnails whenever you change those settings, switch themes or replace images. Without that, WordPress keeps serving the old sizes.

    Two caveats. Enlarging a small photo won’t bring back detail. And doubling thumbnail dimensions for high-density screens makes them sharper but heavier. Shop and archive pages show smaller versions on purpose, so judge sharpness on the single product page.

    Alt text is a separate job from compression

    Compression makes images faster. Alt text makes them understandable to screen readers and to search engines. The W3C’s images tutorial says alt text should reflect what the image is for: describe informative images, describe the action for linked or button images, and use alt="" only for purely decorative ones. Google’s image guidance says it finds images in the src of an <img> element and doesn’t index CSS background images. A product photo set as a background is invisible to image search. The same rules apply in galleries, as our guide to adding a WordPress gallery lightbox explains.

    When to stop and get help

    Stop when the fix needs server changes you can’t make: NGINX rules, memory limits, missing image libraries or firewall allowlists. Your host’s support team can do those, and doing them by guesswork can take the site down. If you would rather not do the work yourself, SiteSelf handles image and speed fixes on request. It needs hosting (SSH) access for file and server work, and it reports what it changed and what it checked on the live page.

    Frequently asked questions

    What size should WordPress images be?

    No single number fits every site. Use the largest width the theme displays the image at, or about twice that for high-density screens. For WooCommerce, use at least 800 x 800 px. The 2,560 px figure is where WordPress starts scaling uploads down, not a target.

    Do I need an image optimization plugin?

    No. A small site that resizes and compresses every image before upload can do without one. A plugin earns its place when many people upload, when you have an existing library to process, or when you want WebP delivery handled for you. Use one, not several.

    Should I use WebP or AVIF?

    Start with WebP. It works in modern browsers and is easier on the server. AVIF can make smaller files, but encoding it takes more server effort and your server’s image library has to support it, so test it on your host before converting a whole library.

    Can I undo optimization if images look worse?

    Only if the originals still exist. Most optimizers have a setting to keep a backup of each original. Turn it on before a bulk run. It uses extra storage, but you can restore or reprocess without hunting for source files.

    Does editing alt text in the Media Library update my posts?

    Not always. Images already placed in posts often keep the alt text they had when they were inserted. Check the image block in each post where accuracy matters.

    WordPress Settings Media screen with image size settings
    WordPress automatically generates individual image files for every default dimension defined in the Media Settings panel. · Source: wordpress.org

  • How to install a WordPress theme without breaking it

    Key takeaways

    • Installing and activating are separate steps. An installed theme does nothing to the live site until you click Activate, so you can install it now and switch later.
    • “The theme is missing the style.css stylesheet” almost always means you uploaded a marketplace bundle. Unzip it on your computer and upload the theme ZIP inside it.
    • Upload-size, “Could not create directory” and missing “Add New” errors are host or account limits. Uploading the file again will not fix them. Never set permissions to 777.
    • After activation, check menu locations, widgets, forms and, on a store, cart, checkout and My Account. Also check that a staging noindex setting did not come with you to production.

    You bought a theme, downloaded the ZIP, and WordPress replied with “The package could not be installed.” Or the install worked and your site looks nothing like the demo. Both are common, and both have plain causes.

    WordPress has three ways to install a theme: from the WordPress.org directory, by uploading a ZIP, or by copying the theme folder to the server. Each route ends the same way, with a valid theme folder inside /wp-content/themes/. This guide covers each route, what each error means, and what to check once the theme is live. If you are choosing between themes, start with how to choose WordPress templates for business.

    What to do before you install anything

    Take a backup of the files and the database, and make sure you know how to restore it. A backup you have never restored is a hope, not a plan. Our explainer on what a backup plugin actually covers explains why “full backup” does not always mean full.

    Then check four things:

    • Compatibility. Compare the WordPress and PHP versions the theme supports with what your site runs. On a store, check the WooCommerce version too.
    • What the current theme provides. Write down your menus, widgets, custom CSS, homepage settings and any theme shortcodes. A new theme may not carry them over.
    • Where to test. WordPress.org’s theme documentation recommends a test site for proper testing. On a live business site, use your host’s staging copy if it has one.
    • Access. Make sure you have SFTP or file-manager access. If an activation takes the dashboard down, that is how you get back in.

    How to install a theme from the WordPress directory

    Use this route for free themes listed on WordPress.org. You need an administrator account.

    1. Go to Appearance → Themes and click Add New Theme.
    2. Search by name, or filter by feature.
    3. Click Preview to see the theme with sample content.
    4. Click Install.
    5. Click Live Preview to see it with your own content. On a block theme, the preview opens in the Site Editor.
    6. Click Activate when you are ready for visitors to see it.

    If you clicked Install and nothing changed, that is expected. Installing makes a theme available. Activating makes it live. You can leave a theme installed and inactive until it is ready.

    How to upload a premium theme from a ZIP

    Themes from marketplaces and independent developers arrive as a download. The catch is that the download is often a bundle: documentation, licence files, a child theme, and the real theme ZIP inside it.

    1. Unzip the download on your computer. Do not upload anything yet.
    2. Find the installable theme ZIP. It is usually named after the theme. Some marketplaces let you download the installable theme file on its own, so check before you dig through the bundle.
    3. In WordPress, go to Appearance → Themes → Add New Theme → Upload Theme.
    4. Choose the theme ZIP, still zipped, and click Install Now.
    5. Preview it, then activate.

    Upload it under Themes, not Plugins. A theme ZIP uploaded at Plugins → Add New gets “No valid plugins were found.” If the theme needs companion plugins, such as a builder or a demo importer, install them after the theme. Our guide to installing a WordPress plugin safely covers that step.

    How to install a theme manually with SFTP or WP-CLI

    Use this route when the dashboard upload is blocked by a size limit, or when you want to see the files yourself.

    1. Unzip the theme ZIP on your computer.
    2. Connect with SFTP or open your host’s file manager.
    3. Upload the theme folder to /wp-content/themes/. Do not use /wp-content/uploads/, which is for media.
    4. Check the nesting. You want /wp-content/themes/theme-name/style.css, not /wp-content/themes/theme-name/theme-name/style.css.
    5. Go to Appearance → Themes. The theme should now appear there. Activate it.

    The difference between the routes trips people up. The dashboard uploader wants the ZIP. SFTP wants the unzipped folder.

    Developers and anyone managing several sites can use WP-CLI. It accepts a directory slug, a local ZIP or a URL, and --activate is optional:

    wp theme install twentytwentyfive
wp theme install ../my-theme.zip --activate

    What a correct install looks like

    The theme appears in Appearance → Themes with its screenshot and name. Inside its folder, WordPress’s Theme Handbook expects a style.css plus index.php for a classic theme, or style.css plus templates/index.html for a block theme. If those files are missing or sit one folder too deep, WordPress will not recognise the theme.

    Why the install failed, and what each error means

    Read the exact error before you try again. Each message points at a different cause, and only the first is about the file itself.

    WordPress theme install error: the theme is missing the style.css stylesheet
    WordPress halts the process with a missing stylesheet warning when a full marketplace package is uploaded instead of the actual theme archive. · Source: help.market.envato.com

    “The theme is missing the style.css stylesheet”

    The full message is “The package could not be installed. The theme is missing the style.css stylesheet.” In practice this is almost always the outer marketplace bundle, not the theme. It can also be a plugin ZIP, a theme built for another platform, or a broken package. Upload the inner theme ZIP instead. Do not create a style.css by hand to get past the error. If the real theme ZIP still fails, ask the developer for a working copy.

    “The uploaded file exceeds the upload_max_filesize directive in php.ini”

    Your host caps the upload size. First, make sure you are not uploading the whole bundle, which is often what makes the file too big. Then open Tools → Site Health → Info and look under Media handling and Server to see the limit. Ask your host to raise it, or install over SFTP, which skips the limit.

    “Could not create directory”

    WordPress cannot write to /wp-content/themes/. Site Health → Info → Filesystem Permissions shows which directories are writable. WordPress’s handbook gives 755 for directories and 644 for files as a common setup, and notes that the right values depend on your host. It also warns against 777. World-writable files are a security risk, and wrong permissions can take a site offline. Ask your host to fix the ownership instead.

    “Destination folder already exists”

    A folder with that name is already in /wp-content/themes/. Either the theme is already installed, or an earlier install failed halfway. Check Appearance → Themes first. If WordPress offers to replace the current version with the upload, that is the clean route. Otherwise, take a backup, then rename or remove the leftover folder over SFTP and reinstall. Make sure it is not the active theme, or the parent of your active child theme.

    No “Add New” or “Upload Theme” button

    This is about your account, not your file. On Multisite, only the Super Admin has the install_themes capability, so ask whoever runs the network. Our Multisite installation guide explains how that split works. On WordPress.com, whether you can upload a theme depends on your plan. Some hosts also turn off uploads.

    How to install a child theme

    A child theme holds your custom code, so a parent theme update cannot overwrite it. The parent has to be installed but does not need to be active. Install the parent, install the child the same way, and activate only the child. The child’s style.css names its parent in a Template: line. If you delete the parent, the child stops working.

    If you change theme code, do it in the child theme, never in the parent’s files. Our guide to theme customization that survives updates shows what belongs where.

    What to check after you activate

    The “New theme activated” notice means the switch happened. It does not mean the site works. Go through it the way a visitor would.

    • Menus and widgets. Each theme defines its own menu locations and widget areas, so items can end up unassigned. Reassign them under Appearance → Menus or in the Site Editor.
    • The demo look. Activating a theme does not import its demo. Demo content usually needs the theme’s own importer. A generic WordPress XML export will not rebuild it. Run any importer on staging first, because it writes pages and settings into your site.
    • Theme features. Shortcodes, sliders and builder layouts from the old theme may now show as raw text or disappear.
    • Forms and mobile. Submit every form. Check the menu on a real phone.
    • Accessibility. Tab through the header and menus with the keyboard. Check that focus is visible and that text has enough contrast.
    • Search visibility. If you built the site on staging, make sure production is not still set to noindex. Google’s documentation says a noindex tag keeps pages out of Search results. If URLs changed, add redirects.
    • Speed. Test your real pages, not the demo. Starter templates can add a lot of weight.
    WordPress menu locations to reassign after installing a new theme
    Under the Manage Locations tab, dropdown selectors allow you to reconnect existing navigation menus to the newly activated theme display areas. · Source: wpmarmite.com

    On a WooCommerce store, WooCommerce’s theme guide says to test My Account, cart and checkout rather than trusting the demo. WooCommerce → Status lists the theme’s template overrides and flags any that are out of date. If something breaks, switch to Storefront on staging. If the problem goes away, the theme is the cause.

    Installing the theme is usually the smallest part of a redesign. Configuration, content and testing are the rest. If you would rather hand that part off, SiteSelf’s page on design changes to an existing site covers what the agent does with styles and templates.

    When to stop and get help

    If the site goes blank or shows a fatal error after activation, do not keep clicking. WordPress Recovery Mode, available since version 5.2, emails the site admin a link that can get you back into the dashboard. If that email never arrives, connect over SFTP and rename the new theme’s folder. WordPress then falls back to an installed default theme. The white screen guide walks through the rest.

    Change one thing at a time, and write down the exact error before you contact the theme developer or your host. Hand the job over if the error names a server setting you cannot reach, the store’s checkout fails on the new theme, or the fix means editing the theme’s PHP and you do not have a staging copy to try it on.

    Frequently asked questions

    Will changing my theme delete my posts and pages?

    Your posts and pages are stored in the database, so switching themes does not remove them. What can change is how they look: layouts, widget placement, menu locations and theme-specific shortcodes. A demo importer is different, because it writes content into your site. Run it on staging.

    Can I upload the unzipped theme folder through the dashboard?

    No. Appearance → Themes → Upload Theme only accepts a ZIP. If you have an unzipped folder, upload it to /wp-content/themes/ over SFTP or the host’s file manager. Some computers unzip downloads automatically, so check you still have the .zip file.

    Why doesn’t my site look like the theme demo?

    The demo is built from content, images and settings the theme does not install. Most premium themes ship a separate demo importer or starter-site plugin. Even after importing, you still have to replace the sample content with yours.

    Should I keep the old theme installed?

    Yes, until the new one has passed your checks on the live site. Also keep one default theme, such as a recent Twenty-something theme, installed. WordPress falls back to it if the active theme breaks. Remove unused themes once you are settled, because each one is code that needs updating.

    How do I update a theme I installed from a ZIP?

    Premium themes often don’t update through WordPress.org, so the process depends on the developer. Our guide to updating a WordPress theme without losing work covers each case.

  • How to choose WordPress templates for business

    Key takeaways

    • “Template” can mean a theme, a starter site, a page-builder kit or a page pattern. If you upload the wrong one through the theme installer, WordPress says the theme is missing the style.css stylesheet.
    • Import starter templates on a fresh install or a staging copy. Their design settings apply to the whole site, and on a live Elementor site they have changed the colours, fonts and breakpoints of every page.
    • Check which page builder a template needs before you judge its looks. W3Techs detects Elementor on 31.5% of WordPress sites, and many starter designs won’t import without it.
    • Folio3 prices a premium theme at $40 to $200. Freshy puts a freelancer-built 5 to 15 page business site at $2,000 to $5,000. Most of the cost is content and setup, not the template.

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

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

    What “template” actually means in WordPress

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

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

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

    WordPress theme installer error saying the theme is missing the style.css stylesheet
    Attempting to install an entire download bundle rather than the standalone theme archive triggers the missing stylesheet error. · Source: support.17thavenuedesigns.com

    When a template is the right choice for a business site

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

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

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

    Why your site won’t look like the demo

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

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

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

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

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

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

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

    How to install a template without breaking an existing site

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

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

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

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

    What a template costs compared with the whole site

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

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

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

    What to check after launch

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

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

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

    Frequently asked questions

    What is the difference between a WordPress theme and a template?

    A theme controls the design of the whole site and installs under Appearance > Themes. “Template” is looser. It can mean a starter site imported by a plugin, a page-builder kit, or a layout for a single page. Business buyers usually mean a whole pre-designed site, which in practice is a theme plus imported starter content.

    Will importing a starter template delete my content?

    Usually not. Your posts and pages stay. What changes is the global design: colours, fonts, layout and breakpoints can switch across the whole site. That is why the import belongs on a fresh install or a staging copy.

    Should I pick a multipurpose theme or an industry-specific one?

    There is no measured answer. Multipurpose themes with large starter libraries tend to get updates for longer, which is why some agencies have moved to them. They also carry features you won’t use. Whichever you choose, the maintenance record and the dependency list matter more than the niche on the label.

    Can I change my template later?

    Yes, and your content comes with you. Layouts built with the old theme’s builder, shortcodes or custom widgets don’t, so expect to rebuild the homepage and any designed landing pages. Do the switch on staging first.

    Does a template affect speed and SEO?

    It is one factor. Plugins, image sizes, scripts and hosting count just as much. Feature-heavy themes load more CSS and JavaScript than a simple site needs, so a lighter base gives you more room. Test your real pages, not the theme’s demo.

    What should a WooCommerce store check in a template?

    Check that the theme declares WooCommerce support, then test the product, cart and checkout pages with your own products on staging. Back up the database before any theme change, because orders and products live there.

  • Layout and design of a website on WordPress

    Key takeaways

    • On a block theme, design lives in Appearance > Editor. Styles set colours, type and layout for the whole site. Templates set the layout of a page type. The page itself holds only its content.
    • Editing a shared template, such as WooCommerce’s Single Product template, changes every page that uses it. Find the layer and how far it reaches before you edit anything.
    • When a live page stops matching the editor, regenerate the builder’s CSS first. Then clear the plugin, host or CDN and browser caches, and test in a private window. This fixes many cases but not all of them.
    • Some baselines are fixed numbers: text contrast of 4.5:1 (3:1 for large text), content that reflows at 320 CSS pixels, and Cumulative Layout Shift below 0.1.
    • Builders like Elementor store spacing and visibility separately for each device. Fixing desktop does not fix the phone.

    A WordPress site rarely has one place where its look lives. A page’s header might come from a template, its colours from global Styles, its spacing from a page builder and its final look from whatever CSS file the cache decided to serve. That is why “just change the layout” can take five minutes on one site and an afternoon on another.

    This article covers two things. First, what a good layout does for the people using it. Second, where each part of that layout is controlled on WordPress, so you can change it on purpose and fix it when it breaks. If you already know the basics of editing pages in WordPress, this is the layer underneath.

    What layout and design decide on a page

    Layout is order and arrangement: what appears first, what sits next to what, and what happens to that arrangement on a narrow screen. Design is the visual system on top: type, colour, spacing, imagery. Visitors feel both as one thing. Either the page answers their question quickly or it doesn’t.

    Practitioners on r/marketing, r/smallbusiness and r/woocommerce give much the same advice. Make the offer clear on the first screen. Show proof, such as real photos and reviews. Keep each page focused on one next step. Design for the phone first. Cut animation and video that make people wait. That advice is consensus, not measured conversion data, and most of it is about structure and copy rather than visual polish.

    Some of it can be measured. The W3C’s guidance on contrast asks for a ratio of at least 4.5:1 between text and background, or 3:1 for large text. The WCAG reflow criterion expects content to work at a width of 320 CSS pixels without scrolling in two directions, except where a two-dimensional layout is needed. Google’s Core Web Vitals treat a Cumulative Layout Shift below 0.1 as good. That metric measures how much things jump around while the page loads, so it is a layout number as much as a speed number.

    One more check. Headings that only look like headings, such as bold, large paragraph text, give screen readers and search engines no structure. A page can look fine and still be broken underneath. This often happens on sites where content is pasted in from documents by several editors over the years.

    Where a WordPress site’s layout actually lives

    Start by finding out which kind of theme you run. WordPress.org’s documentation says the Site Editor only exists when a block theme is active. If Appearance shows an Editor item, you have a block theme. If it shows Customize instead, you have a classic theme, and design settings live in the Customizer, the theme’s own options panel or a child theme.

    On a block theme, the layers look like this:

    LayerWhat it controlsWhere you change itHow far a change reaches
    Global StylesColours, typography, content width, spacing defaultsAppearance > Editor > StylesEvery page
    TemplatesThe layout of a page type: single post, page, product, archive, 404Appearance > Editor > TemplatesEvery page using that template
    Template partsHeader, footer, other shared regionsAppearance > Editor > Patterns or Template partsEvery template that includes the part
    Page contentBlocks inside one pageThe page editorThat page
    Page builderThe page’s layout, in the builder’s own data and CSS filesThe builder’s editorThat page, or the builder’s global settings
    Plugins and cachesExtra CSS, optimised or combined files, cached copiesEach plugin’s settings, your host, your CDNAnything they touch
    WordPress Site Editor Styles panel controlling global layout and design
    The Global Styles panel centralizes site-wide design settings, letting you manage typography, colors, and layout across every page in one place. · Source: developer.wordpress.org

    WordPress.org describes the Styles panel as the place that sets the overall look and layout of a site at a global level. Change the body font there and every page changes. Change it inside one paragraph block and only that block changes, and it will ignore future global edits. Most “inconsistent design” comes from many small one-off overrides like that. Our article on why a font change is not showing walks through one common case.

    Why a shared template edit changes every page

    WooCommerce’s documentation is blunt about this. Editing a template changes the layout for every page, post or product that uses it. Move the price below the gallery in the Single Product template and you have moved it on every product in the store. That’s usually what you want. It isn’t what you want when you meant to change one product.

    The reverse problem is just as common. Someone tries to change the header on one page, edits that page and finds no header to edit, because the header lives in a template part. Before you edit anything, ask two questions: which layer owns this element, and how many pages use that layer? Our guide to customizing a WordPress template safely covers assigning a different template to a single page.

    Why the live page stops matching what you designed

    Support threads on wordpress.org and Reddit point to the same few causes, roughly in this order of how often they come up. That ranking comes from how often people report each one, not from a survey, but it is the order worth checking in.

    1. Stale generated CSS or a cache serving old files

    Page builders write CSS to files. Elementor’s sit in /wp-content/uploads/elementor/css/, one per post plus a global file. Caching plugins, your host, a CDN and the browser can each keep serving an old copy, or a cached page can point at a CSS file that no longer exists. The result is a page that looks unstyled, half-styled or styled with last week’s design.

    The fix Elementor documents, in this order:

    1. Take a backup.
    2. In wp-admin, open Elementor’s Tools screen and run Clear Files & Data (labelled Regenerate Files in older versions).
    3. Clear your caching plugin’s cache, then your host’s or CDN’s cache.
    4. Load the page in a private browser window, logged out.
    Elementor Tools screen with Clear Files and Data for fixing website layout
    Using the Clear Files and Data tool forces Elementor to regenerate outdated stylesheets before downstream caches take over. · Source: elementor.com

    The most common mistake is doing step 2 without step 3. The builder makes fresh files, but cached pages still point at the old ones. In the wordpress.org thread “Site look and feel is gone”, an OceanWP site lost its styling across every page and the host blamed the theme. A missing set of Elementor assets after a URL change turned out to be the cause, and regenerating them fixed it. The owner noted that the button was not where anyone would think to look.

    Optimisation features can be the cause in their own right. One LiteSpeed Cache user reported that turning off its CSS and JS optimisation fixed their layout only for about a day. Deactivating the plugin fixed it for good, at the cost of speed. If your layout breaks after caching settings change, turn off the CSS optimisation options (combine, minify, unused CSS, critical CSS) one at a time to find the one responsible.

    2. A plugin, theme or version conflict, often right after an update

    If the layout broke when something updated, suspect a conflict. WooCommerce’s conflict-testing guide sets out the standard method: switch to a default theme, deactivate other plugins, then reactivate them one at a time until the problem comes back. Reactivating everything at once tells you nothing.

    Doing that on the live site changes what visitors see. The Health Check & Troubleshooting plugin avoids this: its troubleshooting mode disables plugins and switches the theme for your logged-in session only. A staging copy works too. Also read the changelogs of the builder and its add-ons. A known bug that a newer version fixes beats regenerating files ten times.

    3. A setting that only applies to one device

    When a page is fine on desktop and broken on a phone, the cause is usually a setting that only applies on mobile. Elementor’s mobile troubleshooting guide points to margins under Advanced > Layout, which are stored separately for each device, and to visibility settings that hide elements on some screens. Fixed pixel widths are the other usual suspect: a 600px-wide box cannot fit a 390px-wide screen.

    Switch the editor to the failing device view and fix that breakpoint specifically. Prefer percentage or flexible widths. Then check on a real phone. Previews are close, but not the same.

    Elementor mobile responsive view showing device-specific website layout settings
    Elementor allows designers to toggle section visibility exclusively for mobile screens without affecting desktop viewports. · Source: elementor.com

    4. The change went into the wrong layer

    Sometimes nothing is broken. A global style is overriding a page setting, or a page override is ignoring a global one, or a theme file is overriding the template you edited. Go back to the table above and trace which layer owns the element.

    When to stop and get help

    Stop when the standard steps have failed twice. In one 2026 wordpress.org thread, an Elementor and LiteSpeed site on Hostinger kept returning 404 errors for CSS files. The breakage moved from page to page through repeated purges and regenerations. Cases like that need someone who can read server logs, check file permissions on the uploads folder and compare plugin versions.

    Error messages tell you which direction to look. “Preview Could Not Be Loaded” is an Elementor editor problem. A 500 error is a server or PHP problem, not a spacing problem. “Broken theme and/or stylesheets missing” means the theme upload or install went wrong. A 404 on a post-1234.css file means a generated CSS file is missing.

    How to keep a layout consistent as the site grows

    Sites drift. New editors paste content, campaigns add one-off sections, plugins add their own buttons in their own colours. Three habits slow this down.

    Change the global setting first. If every button needs to be darker, change the button style in Styles or the theme’s settings, then remove the one-off overrides that now look wrong. Don’t fix forty pages one at a time.

    Build repeated sections once. A pricing row, a call to action or an FAQ block that appears on many pages belongs in a synced pattern or template part. Then one edit updates every copy. It takes longer the first time and saves time every time after that.

    Check structure, not just looks. A short review every quarter catches most drift: real headings in order, contrast on new colours, forms usable on a phone, nothing jumping as the page loads.

    The bigger decision is whether to refine or redesign. Refine when the theme supports your content, URLs work and the problems are hierarchy, spacing, mobile behaviour or tired images. A rebuild is worth its cost and risk when the theme stops you doing the job, templates have become impossible to maintain or the builder’s output is too heavy to fix. Our article on theme customization that survives updates covers the middle ground.

    What changes when an agent makes the layout edit

    Most layout work is small: a darker button, tighter mobile spacing, a section moved above another. The process around it is not. You find the right layer, check how many pages it affects, make the change, clear the caches and confirm it on the live page. With an agent, you describe the outcome and the agent does those steps.

    Example request: “On the Services page the contact button sits below a huge image on phones. Move the button above the image on mobile and make the button colour match the one on the homepage.”

    On a block-theme site, SiteSelf would work out whether the button and image sit in the page content or in a template. It would say what is about to change and whether that change can be undone. If the colour lives in global Styles, it would say that changing it there affects every button, and offer to apply it to that page only. After the change it fetches the live page, checks that the new order and colour are in what is served, and reports in chat what changed. The work is recorded.

    Access depends on where the change lives. Content, template and Styles work runs through the SiteSelf Connector plugin from the WordPress.org directory. Edits to theme files, child-theme CSS or anything on the server need hosting (SSH) access.

    There are limits. Pages owned by Elementor, Divi or Beaver Builder are refused at the moment of work, with the reason, so builder pages stay with the builder. The check is a fetch of the page and a plain-language report, not a screenshot or a test on real devices, so look at the page on your own phone too. Nothing runs on a schedule: the agent works when you ask. The page on website edits through chat shows what this kind of request covers. Larger visual work, such as new typography or brand colours across the theme, is covered under design changes on your existing site.

    Frequently asked questions

    Do I need a theme if I use a page builder?

    Yes. The theme still controls the templates and global styles around the builder’s content, such as the header, footer, archives and default fonts. Its CSS can also clash with the builder’s. That is why Elementor’s conflict tests use its minimal Hello theme or a default WordPress theme.

    Is the block editor or a page builder better for layout?

    It depends on who maintains the site and how complex the layouts are. Published benchmarks from 2023 onward generally show block editor pages lighter than Elementor pages, but setups vary and no single ranking holds. If you have no builder yet, see how far the Site Editor and patterns get you first.

    Why does my site look different when I’m logged in?

    Many caching setups skip the cache for logged-in users. You see the current version while visitors get an older cached copy. Always check changes in a private window while logged out.

    Can I change my layout without touching code?

    On a block theme, mostly yes. Styles, templates, template parts and patterns are all edited visually in Appearance > Editor. Classic themes depend on what the Customizer and theme options expose. Anything beyond that means a child theme and some CSS or PHP.

    How do I hide something on mobile without hurting the page?

    Hide decoration, not substance. Content that matters on desktop, like prices, contact details and key text, should still be there on a phone. Search engines index the mobile version, and visitors on phones need the same answers.

  • How to write and change coming soon text in WordPress

    Key takeaways

    • Use a simple formula: what is coming, the date only if it is confirmed, one line of benefit, and one next step. No published test shows that any particular wording converts better.
    • New WooCommerce stores that finish onboarding start in Coming soon mode. You switch it off under WooCommerce > Settings > Site visibility > Live.
    • The ‘Great things are on the horizon’ text can be edited directly only in a block theme. Classic-theme stores can switch to a block theme for a moment, edit the template, then switch back.
    • If the site still shows the placeholder after you turned it off, check it logged out and purge every cache layer. In one wordpress.org case, a stale page stayed up for almost a day.
    • ‘Briefly unavailable for scheduled maintenance’ does not come from a plugin. It comes from a leftover .maintenance file in the site root, and deleting that file fixes it.

    People who search for coming soon text usually need one of two things. Some are writing the page and want words that make visitors come back. Others want to change or remove words that are already on their site, often “Great things are on the horizon”, and can’t find where they live. This guide covers both, in that order.

    The second job is harder than it looks because WordPress has no single coming soon setting. WooCommerce, a plugin, your host or a leftover update file can each put up the placeholder, and a cache can keep it showing after you turn it off. If you are building the page from scratch, our guide on building a landing page in WordPress covers the page itself. This article covers the words and the switches.

    What should a coming soon page say?

    Say what is coming, who it is for, and what the visitor should do now. Copy guides from WPForms and SiteGround Academy agree on this short structure: a headline, a brief explanation and one clear next step. Nobody has published test data showing that one wording beats another, so treat any template as a starting point, not a proven formula.

    A formula that works for most launches:

    [What’s coming] is launching [date, only if confirmed]. We’re building [one line of benefit]. [One action: join the list, call us, get early access].

    Applied to a few common situations:

    • A new online store: “Hand-thrown stoneware, made in small batches. The shop opens on 3 March. Join the list for first pick of the opening batch.”
    • A service business on a new domain: “Our new site is on its way. We’re open as usual. Call [phone] or email [address] to book.”
    • A publisher starting a new section: “A weekly briefing on local planning decisions, starting this spring. Sign up and the first issue comes straight to you.”
    • A product with something to show: “We’re building a booking calendar for dog groomers. Here’s the first screen. Get early access before we open it up.”

    The weak version is the one most sites ship: “Launching soon. Subscribe to our newsletter.” A small-business owner on Reddit got this advice: name the offer and the audience instead, as in “We’re developing X for Y; sign up for an exclusive preview and early access.” They were also told to show the real product, even if it is just one photo. If the business is already trading, the most useful words on the page are your phone number and opening hours.

    Should you add a countdown or an email form?

    Add a countdown only when the date is fixed. A timer is a promise. When it hits zero and nothing happens, visitors stop trusting the page. If the date might slip, write “Opening this spring” and update it when you know more.

    An email form is worth adding only if you will actually write to the list. In the same Reddit discussion, people suggested sending a real update every two to three weeks so the list doesn’t go cold. Results vary a lot. One founder reported 1,033 waitlist signups from about 3,500 visitors after posting a video demo, but said they didn’t know how many of those became customers. Other marketers report too little interest to justify the work. A visible product and a reason to sign up make more difference than the form itself.

    One more decision comes before any of this. If your site is already live and you are redesigning it, you probably don’t need a coming soon page at all. Keep the current site running, build the new version on staging, and leave unfinished pages out of the menu.

    Where does the coming soon text on your site come from?

    It comes from whichever layer switched the placeholder on, and each layer has its own off switch. Turning off one doesn’t touch the others. In one wordpress.org thread, a user disabled and then deleted a coming soon plugin and still saw the page. Their host had to fix it. Start by reading the exact text and footer on the page, then match it here:

    What you seeLikely ownerWhere to change it
    “Great things are on the horizon”WooCommerce Coming soon modeWooCommerce > Settings > Site visibility
    A designed page with your logo, maybe a countdownA plugin such as SeedProd, LightStart, CMP or ElementorThat plugin’s own settings screen
    “Coming Soon!” with a footer that names your hostYour hosting companyThe host’s dashboard or its WordPress plugin
    “Briefly unavailable for scheduled maintenance. Check back in a minute.”A leftover .maintenance fileDelete the file from the site root
    A coming soon notice on one product onlyA product-level setting, such as Coming Soon Products for WooCommerceProducts > Edit Product > Product Data > Coming Soon
    A message on a site hosted at WordPress.comWordPress.com site visibilitySettings > Reading > Site Visibility > Public

    Changing the text and changing the mode are separate actions. Editing the WooCommerce landing page changes what it says, not whether visitors see it. The same goes for a product’s Coming Soon Text field, which doesn’t switch off that product’s Coming Soon Mode.

    How to change “Great things are on the horizon” in WooCommerce

    WooCommerce shows its own landing page while the store is in Coming soon mode. According to WooCommerce’s documentation, new stores that complete onboarding start in that mode, and stores that were already live start as Live. Where you edit the text depends on your theme.

    WooCommerce Site visibility settings with Coming soon and Live options
    Selecting the Live radio button under Site visibility officially publishes your storefront to the public rather than just modifying the placeholder page. · Source: woocommerce.com

    If you use a block theme (Twenty Twenty-Five, for example):

    1. Go to WooCommerce > Settings > Site visibility.
    2. Follow the link to customise the Coming soon page. It opens the template in the Site Editor.
    3. Edit the heading and text, add your signup block or contact details, and save.
    4. Open the site in a private window to see what visitors see.

    If you use a classic theme such as Storefront, there is no direct editor. The workaround from WooCommerce’s own support forum takes about ten minutes:

    1. Take a backup, then switch to a block theme under Appearance > Themes.
    2. Edit and save the Coming soon template as above.
    3. Switch back to your classic theme.
    4. Check the page logged out.

    Don’t edit WooCommerce’s plugin files to change the wording. Support volunteers discourage it because the next WooCommerce update overwrites your change. If the theme switch feels too risky on a store taking orders, practitioners suggest two other routes: a dedicated coming soon plugin, or a custom page plus a small snippet that redirects logged-out visitors to it.

    To take the store live, set Site visibility to Live and save. Watch for the “Apply to store pages only” option. With it on, the rest of the site looks public while the shop, cart and product pages stay hidden. Hiding the admin bar badge changes nothing for visitors.

    Why does the site still say coming soon after you launched?

    The usual answer is that you are logged in or a cache is serving an old copy. Work through these in order. They are ranked by how often they come up in support threads, which is a rough guide rather than a measured rate.

    You are checking while logged in

    SeedProd, WooCommerce and WordPress.com all show the real site to logged-in users on purpose. An owner can look at a live-looking site while every visitor sees the placeholder, or the other way round. Always check in a private window. Our guide to landing page plugins and visibility modes explains the same trap from the publishing side.

    A cache is still serving the placeholder

    Clearing your browser cache doesn’t clear the copies held by a caching plugin, your host or a CDN. In one wordpress.org thread, a maintenance page was still showing almost 24 hours after it was disabled. The fix was purging the host’s Varnish cache from the Cloudways dashboard. Purge in this order: caching plugin, host cache, CDN, then browser. A quick test is to load the homepage with a junk query string such as /?nocache123. If that version is live and the plain URL is not, a cache is the culprit.

    You switched off the wrong layer

    Go back to the table above. A host placeholder survives turning off WooCommerce, and a WooCommerce placeholder survives deleting a plugin. If none of the switches explains it, check that the Shop page is still assigned under WooCommerce > Settings > Products. Then deactivate other plugins one at a time on staging to find a conflict.

    The message is “Briefly unavailable for scheduled maintenance”

    This comes from WordPress, not from a plugin. WordPress writes a .maintenance file while an update runs, and if the update is interrupted, the file stays behind. The WordPress Advanced Administration Handbook gives the fix: delete .maintenance from the folder that contains wp-admin, using FTP or your host’s file manager, then run the update again. Wait a few minutes first so you don’t delete it mid-update. The file starts with a dot, so turn on “show hidden files” if you can’t see it. If the update keeps failing, our guide to fixing plugins that stop working covers half-finished updates.

    WordPress briefly unavailable for scheduled maintenance message in a browser
    The default maintenance notice displayed by the browser indicates an unresolved .maintenance file rather than an active coming soon plugin. · Source: kinsta.com

    Coming soon or maintenance mode: which does Google expect?

    Use coming soon mode for a site that has never launched, and maintenance mode for short work on a live site. They send different signals to search engines. Google’s guidance on pausing a website is to return HTTP 503 only for an urgent shutdown of a day or two. For longer closures, it recommends a placeholder page that returns 200 and can be indexed. Google also warns against blocking crawling with robots.txt or returning 503 for the robots.txt file.

    SeedProd’s WordPress.org listing says its Coming Soon mode returns 200 and its Maintenance mode returns 503. Elementor’s help pages describe the same split. Other plugins vary, so check the real response instead of trusting the label:

    curl -I https://example.com/

    The first line of the output shows the status, for example HTTP/2 200 or HTTP/2 503. If a site that has been in “maintenance” for weeks is still returning 503, switch it to coming soon mode or launch it.

    A placeholder is a curtain, not a lock

    A coming soon page hides the front door. It doesn’t protect the content behind it. Published pages can still be reached through direct URLs, feeds, sitemaps or a plugin bug. Anything that must stay private belongs on staging or behind real access control, such as a password-protected WordPress page.

    The same goes for client work. Staging is the usual place for client previews, though some plugins offer a bypass link so clients can see a production site behind the placeholder. Freelancers on Reddit strongly warn against using a placeholder to take down a client’s live site over an unpaid invoice. Put payment and handover terms in the contract and hold back deployment instead.

    If you would rather not chase the switch yourself, SiteSelf can edit the page or take it live from a chat request. Text and visibility settings need only the connector plugin. Deleting a stuck .maintenance file needs hosting access.

    Frequently asked questions

    Does a coming soon page hide my site from Google?

    Not by itself. Coming soon modes usually return 200, so Google can index the placeholder. Maintenance modes usually return 503, and Google treats that as temporary. A noindex tag or a robots.txt block can remove URLs from search, so don’t add either just to keep a placeholder private.

    Why can I see my site but visitors can’t?

    Most coming soon modes let logged-in users through on purpose. Open the site in a private window or on a phone using mobile data to see what the public sees. If that view still shows the placeholder after you switched it off, purge your caches.

    Can I have a coming soon page without a plugin?

    Yes, in two common cases. WooCommerce has its own Site visibility setting, and WordPress.com sites have a Site Visibility option under Settings > Reading. On other self-hosted sites you need a plugin, a host feature or custom code.

    How do clients preview a site that is in coming soon mode?

    WooCommerce lets you share a private link to the store. SeedProd offers a bypass URL. Many agencies prefer a staging copy, because nothing on production is exposed and the client can click around without risk.

    My coming soon page is blank. Is the mode off?

    No. A blank page with the mode switched on usually means the page has no saved content. In SeedProd, the page also has to be Active and Published before it displays. Add content, save, and check again logged out.

    How long should a coming soon page stay up?

    Only until you launch. A placeholder left up for months tells visitors the business has stalled. If the launch keeps slipping, put up a small live site with your real contact details and add pages as they are ready.

  • How to find your WordPress version with or without login

    Key takeaways

    • The best method depends on your access: admin login, file or SSH access, a host portal, or only the public site.
    • Site Health’s Info tab, not the Status tab, lists the version along with PHP and server details. Support volunteers usually ask for exactly this report.
    • Without wp-admin, the $wp_version line in wp-includes/version.php is the definitive answer. Read it and never edit it.
    • A missing generator tag proves nothing, and a ?ver= number can belong to a theme or plugin. If a public reading disagrees with an authenticated one, trust the authenticated one.
    • Hiding your version is optional and won’t patch anything. If the version is behind, update it.

    A plugin refuses to activate because it needs a newer WordPress. A support volunteer asks for your environment details. A security notice names a release and you need to know if your site falls in the affected range. In all three cases the question is the same, and so is the answer: find the version the site actually has installed, not the one a public page seems to show.

    There are many places to see a WordPress version number, and they are not equally trustworthy. Screens and files inside the site report what is installed. Signals visible from outside, such as page source, feeds and scanners, can be removed, filtered or out of date. Which method you use depends mostly on your access. If the dashboard won’t load at all, the file and command-line methods below still work, and our guide to fixing a WordPress white screen covers getting the site itself back.

    Which method fits the access you have?

    Start with the highest row you can reach. Everything above the line reads the installed version. Everything below it guesses.

    Your accessMethodHow much to trust it
    Admin loginTools → Site Health → Info → WordPressAuthoritative
    Admin loginAt a Glance widget, admin footer, Dashboard → UpdatesAuthoritative
    WooCommerce adminWooCommerce → Status → WordPress environmentAuthoritative
    Host portalYour host’s site dashboardAuthoritative, but may need a refresh
    Files (file manager, SFTP)$wp_version in wp-includes/version.phpAuthoritative
    SSHwp core versionAuthoritative
    Public site onlyGenerator tag, feed, readme.html, ?ver= stringsA hint at best

    How to find the WordPress version in the dashboard

    Site Health is the most detailed screen. WordPress.org’s documentation puts it under Tools → Site Health, with an Info tab that reports the version in use along with server, database and plugin details.

    1. Log in to wp-admin as an administrator.
    2. Go to Tools → Site Health.
    3. Click the Info tab at the top. The page opens on the Status tab, which lists problems and recommendations but not the version, and this is where most people get stuck.
    4. Expand the WordPress section. The first rows include Version.
    WordPress Site Health Info tab showing the installed WordPress version
    Navigating to the Info tab within the Site Health screen reveals the dedicated WordPress dropdown section that houses your site details. · Source: www.paidmembershipspro.com

    The Info tab is read only, so you can’t break anything by opening it. If you’re asking for help, use the Copy site info to clipboard button and paste the report into your support thread. It covers the WordPress version, PHP version, active theme and plugin list in one go, which is what a volunteer needs to tell a core problem from a plugin conflict. Our guide to fixing plugins that stop working covers what else to include.

    Three other admin screens that show it

    WordPress.org’s Administration Screens documentation lists two quick spots. The At a Glance widget on the Dashboard home screen names the installed version, and the admin footer at the bottom right of most screens shows it too.

    If At a Glance isn’t there, it hasn’t gone anywhere. Someone turned it off. Open Screen Options at the top right of the Dashboard and tick At a Glance to bring it back.

    WordPress At a Glance dashboard widget showing the WordPress version
    The At a Glance widget displays the current WordPress version and active theme directly below the Screen Options tab used to restore it. · Source: developer.wordpress.org

    Dashboard → Updates also states your current version, and it’s the screen to use when you want to act on the number rather than just read it. It tells you whether a newer release is available.

    WooCommerce stores and managed hosts

    Store operators have a second authoritative screen. WooCommerce’s documentation gives WooCommerce → Status → WordPress environment → WordPress version, with Site Health as the alternative. Be careful not to mix up the WordPress version with the WooCommerce version listed near it.

    Managed hosts show the version in their own panels:

    • WordPress.com (plugin-enabled sites): open the Hosting Dashboard and select the site. The version appears under the site’s title and address. WordPress.com manages core updates, and its support docs say a site one version behind may simply mean a release is still in testing.
    • WP Engine: in the User Portal, go to Sites, choose the environment, and look at Updates on the Overview page. If you updated recently and the number looks old, use Refresh.

    How to find it when you can’t log in

    Lost credentials, a contractor login without admin rights, or a fatal error that takes down wp-admin all lead here. You need either file access or SSH.

    Read wp-includes/version.php

    Open your host’s file manager or connect over SFTP. Find the WordPress install directory, which is often public_html or a folder named after the domain, then open wp-includes/version.php. Look for this line:

    $wp_version = '6.8.3';

    The value in quotes is your core version. Two warnings. First, read the file and close it. Never edit it, because changing the number changes nothing about the code, and WordPress overwrites the file on the next update anyway. Second, ignore $wp_db_version a few lines down. That’s a database schema revision, not the release number.

    If your hosting account holds several installs, such as a staging copy or an old folder from a redesign, check that you’re in the directory the live domain actually serves.

    Run wp core version over SSH

    If your host gives you SSH and WP-CLI, one command answers it:

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

    Run it from the WordPress root, or point it there with --path. If WP-CLI says it can’t find a WordPress install, you’re in the wrong directory, so pass --path and don’t try to fix anything else. On a multisite network, add --url= to target one site. The same command loops easily across several installs. If you look after many sites, see our guide to managing multiple WordPress websites for dashboards that collect this for you.

    How to check the version of a site you don’t manage

    From outside, you can only collect clues. On a well-maintained site, expect most of them to return nothing. That’s usually deliberate hardening, not a broken method.

    • Generator tag. View the page source and search for generator. WordPress core can print <meta name="generator" content="WordPress x.y.z" />, but the developer reference for get_the_generator() shows plugins can filter it. Security plugins, themes and small snippets routinely remove it. A missing tag says nothing about the version, and it doesn’t mean the site isn’t WordPress.
    • The feed. Open /feed/ and look for a <generator> line. The same filter applies, so it’s often gone too.
    • readme.html. Try /readme.html. Many hosts and admins delete or block it, and practitioners disagree on whether it shows a precise current version at all. Treat it as an opportunistic check.
    • ?ver= strings. Scripts and stylesheets often end in ?ver=. The wp_enqueue_script() reference says this value defaults to the WordPress version, but a theme or plugin can set its own number or leave it off. A ?ver= on a file under /wp-includes/ is a stronger hint than one under /wp-content/plugins/, which belongs to the plugin.
    Page source showing the WordPress version in the generator meta tag
    Inspecting the page source reveals the generator meta tag exposing WordPress version 5.2.2 directly in the document head. · Source: www.youtube.com

    Technology lookup tools and vulnerability scanners use the same clues plus file fingerprints. They can suggest a version or a range. They can’t confirm one.

    What to trust when the numbers disagree

    An authenticated reading beats a public one every time. If Site Health says one thing and the page source, a scanner report or readme.html says another, Site Health is right about what’s installed.

    Conflicts usually have boring causes. A page cache or CDN serves HTML generated before the update. A theme or plugin owns the ?ver= you read. A scanner is working from stale data or matching a leftover file. Reports of scanners flagging old versions on sites that had already been updated come up regularly in WordPress communities.

    So don’t edit core files or force a reinstall to make a scanner happy. Confirm the version in Site Health or with wp core version, clear your caches, and check your server logs if something still looks off. The exception is a version.php that disagrees with the dashboard, or core files you didn’t change showing unexpected edits. That points to a failed update or a compromise, and our guide to WordPress malware removal explains how to check.

    Should you hide your WordPress version?

    You can, but it isn’t security. Removing the generator tag stops the most casual lookups and nothing else. Scanners identify WordPress versions from core files, asset URLs and other fingerprints, so the version you hid is still recoverable. And hiding it doesn’t patch a single vulnerability. Google Search Central’s malware-prevention guidance puts the weight on keeping software updated, not on concealing it.

    If you do hide something, hide only the generator tag and then check the page source to confirm it’s gone. Stripping every ?ver= string is riskier. WordPress adds those strings for cache busting, so removing them can leave visitors and your CDN serving old CSS and JavaScript after an update. Only do it if you’ve tested the change with your theme, plugins and cache setup.

    What to do once you have the number

    Write down the full version, all three parts. WordPress treats 6.8 as a major release and 6.8.3 as a maintenance release on that branch, and security advisories are written to that level. “WordPress 6” is not enough to answer a compatibility or security question.

    Then open Dashboard → Updates. If a newer release is available, take a backup before you update. If the site runs a store, a membership area or anything heavily customised, test the update on a staging copy first. WordPress.org’s Updating WordPress guide covers the one-click route and the manual fallback for when it fails. On WordPress.com or WP Engine, the host manages core updates, so check its schedule before you assume the site has been neglected.

    If you would rather not run updates yourself, SiteSelf can handle WordPress core and plugin updates when you ask in chat, reporting what it changed and what it checked afterwards.

    Frequently asked questions

    Does the ?ver= number in my page source show the WordPress version?

    Sometimes. WordPress uses the core version by default for scripts and styles enqueued without their own version, but themes and plugins usually set their own number. A ?ver= on a file inside /wp-includes/ is more likely to be core. Confirm in Site Health before you rely on it.

    Why can’t I find the version in Site Health?

    You’re probably on the Status tab, which opens first. Switch to the Info tab and expand the WordPress section. If Tools → Site Health isn’t in your menu at all, your account doesn’t have administrator rights.

    Do I need a plugin to see my WordPress version?

    No. Every logged-in method above is built into WordPress and costs nothing. Version-info plugins mostly help people who want the details shown in one place, or who collect them across many sites.

    What is $wp_db_version in version.php?

    It’s the database schema revision that the core files expect, stored as a single integer. It changes when an update alters the database structure. It isn’t the release number, so read $wp_version instead.

    My WordPress.com site is one version behind. Is something wrong?

    Probably not. WordPress.com manages core updates itself, and its support documentation says a one-version lag can mean it is still testing the new release. On plugin-enabled sites the Hosting Dashboard shows the current version.

    The generator tag is gone but my site still shows its version. Why?

    Removing the generator tag doesn’t touch the ?ver= strings on core scripts and styles, the feed, or readme.html. Another plugin or your theme may also print its own marker. View the page source after each change and search for your version number to find what is still exposing it.

  • DNS_PROBE_FINISHED_BAD_CONFIG on your WordPress site

    Key takeaways

    • Open the site on a phone using mobile data before you change anything. If it loads there, the problem is your computer, router or resolver, and your site needs no changes.
    • If every network fails, edit records with whichever provider your nameservers point to. That is not always the registrar, and changes made in any other dashboard do nothing.
    • Kinsta says nameserver changes can take 24 to 48 hours, and WordPress.com says up to 72. A wrong record stays wrong no matter how long you wait, so check the records before you blame propagation.
    • To change DNS safely: copy every record, including MX for email, into the new provider, check them, then switch nameservers. Keep the old host running while the change spreads.
    • Look at plugins only after the domain resolves and the site loads. Deactivating plugins does nothing for a DNS error.

    Chrome shows DNS_PROBE_FINISHED_BAD_CONFIG on its “This site can’t be reached” page. It means the browser asked DNS for your domain’s IP address and did not get a usable answer. With no address there was nothing to connect to, so your server never heard from the browser. WordPress never ran.

    That is why the usual WordPress reflexes don’t help here. Deactivating plugins, switching themes or editing the site URL under Settings → General changes nothing, because the failure happened before any of that code could run. Save our guide to plugins that stop working for after the domain resolves again. Your first question is simpler: does anyone else see this error?

    Who else sees the error? Run the scope test first

    Open the site on your phone with Wi-Fi turned off, using mobile data. Then try another computer on your own network, and if you can, ask someone in a different city to try. These three checks take two minutes and tell you which half of this article you need.

    What you seeWhere the problem is
    One computer fails, other devices on the same Wi-Fi workThat computer: its DNS cache, VPN, security software, browser setting or hosts file
    Every device on your Wi-Fi fails, mobile data worksYour router or your internet provider’s resolver
    Several unrelated websites fail tooYour local network or resolver, not your domain
    Your site fails on Wi-Fi and mobile data, from different placesYour domain’s DNS: nameservers, records or DNSSEC
    Your site fails only for people on one mobile carrier or one company networkThat network’s resolver may be filtering your domain

    The last row is easy to miss. Some carriers and corporate networks use DNS security filters that refuse to resolve domains they have flagged as malicious. Your records can be perfect and the site still fails for everyone on that network. The only fix is to contact the filtering provider, and the appeal process varies by vendor.

    Practitioners disagree about which case is more common for this exact error code. Many people who troubleshoot it say it is usually local. Hosting documentation, including Kinsta’s, still lists wrong records and wrong nameservers among the causes of failed resolution. Nobody publishes frequency data for this error, so don’t guess. Let the scope test decide.

    How to fix it when only your device or network fails

    If the site loads anywhere else, leave your site alone. Nothing on it is broken, and changing DNS records now can create a real outage. Work through these steps in order, from cheapest to most involved, and test the site after each one.

    1. Restart the browser fully. Close every window, quit Chrome and reopen it. Then try an Incognito window. If Incognito works, disable extensions one at a time, starting with ad blockers and security extensions.
    2. Restart the router. Unplug it, wait about a minute, plug it back in and give it time to reconnect. This clears a stuck router that is handing out bad DNS settings.
    3. Flush and renew on Windows. Open Command Prompt as administrator and run ipconfig /flushdns, then ipconfig /release, then ipconfig /renew, one at a time. On a Mac, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder clears the local cache.
    4. Try a public resolver as a test. In your network adapter’s DNS settings, set the servers to Google Public DNS (8.8.8.8 and 8.8.4.4) or Cloudflare’s resolver (1.1.1.1 and 1.0.0.1). If the site loads, your internet provider’s resolver was failing.
    5. Test without the layers in between. Pause your VPN or proxy, turn off Chrome’s secure DNS setting (search “secure DNS” in Chrome settings), and on Android check Private DNS. Pause antivirus web filtering just long enough to test, then turn it back on.
    6. Check the hosts file. A leftover entry for your domain in C:\Windows\System32\drivers\etc\hosts or /etc/hosts, often from a past migration test, overrides DNS on that one machine.
    Windows IPv4 properties dialog for setting a public DNS server to fix DNS_PROBE_FINISHED_BAD_CONFIG
    Entering public DNS addresses such as 8.8.8.8 into your network adapter settings isolates device-level lookup issues from your site’s actual server health. · Source: www.ionos.com

    A correct result is simple: the site loads on the device that was failing, in a normal window. If switching resolvers was the fix, decide whether to keep the change. A public resolver can work around a broken provider, but it also changes which DNS service sees your traffic, so an office network should follow its own IT policy.

    Don’t rely on local fixes for one thing: deciding the site is healthy. When you flush your cache or change your resolver, only your own computer is affected. If the site loads for you after that, it proves nothing about your visitors.

    How to fix it when every network fails

    When the site fails everywhere, the problem is in the domain’s authoritative DNS, where the real records live. Google’s Search Central team wrote in 2023 that DNS errors are most often caused by a setting, or a missing setting, on the DNS server. If you don’t manage that server, contact your DNS provider. If you don’t know who that is, ask your host or registrar.

    Find out which dashboard actually controls your DNS

    Your nameservers decide where your records live. That might be your registrar, your host, Cloudflare, or a provider you set up years ago and forgot about. Editing records anywhere else does nothing, and deleting “unfamiliar” records in the real zone can make things worse. One wordpress.org support thread shows the cost of guessing: the owner blamed a security headers plugin for taking down the main site and every subdomain, when the real problem was that the domain’s DNS record had disappeared from Cloudflare.

    On macOS or Linux, run:

    dig example.com NS +short
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 www.example.com +short

    On Windows, nslookup -type=ns example.com and nslookup example.com 1.1.1.1 give the same information. The NS result tells you which provider to log in to. If the A lookups return nothing, the wrong IP, or a SERVFAIL error, the fault is in that zone.

    Compare the records with what your host expects

    Log in to the provider the nameservers point to. Compare the A record for the root domain, and the A or CNAME record for www, against the values your current host gives you. These are separate hostnames, and each needs its own correct record. WooCommerce’s Shopify migration guide, for example, points the root A record at the new host’s IP and points www at the primary domain with a CNAME. Test both example.com and www.example.com in the browser.

    The usual mistakes people make with their own records:

    • An A record pointing at the old host after a move, or at a mistyped IP.
    • Conflicting records for the same hostname. Kinsta’s docs say to remove existing records for a hostname before adding new ones.
    • A record added by mistake while verifying an email or marketing tool. Some registrars add your domain to the host field automatically, so typing the full domain there creates a doubled name.
    • A forgotten Cloudflare setup. If Cloudflare is your DNS provider, you change the origin IP and proxy status in the Cloudflare dashboard. The Cloudflare WordPress plugin covers caching and performance features. It does not manage your DNS records. Cloudflare redirect rules can also send visitors somewhere unexpected, which our guide to WordPress redirects covers.

    Once the right record is corrected, sites often come back quickly. Some owners report minutes. How fast depends on how long resolvers cached the old answer.

    Cloudflare DNS records table showing A and CNAME records for a WordPress domain
    Both the root domain and the www subdomain require distinct DNS entries and matching proxy settings to ensure web traffic resolves correctly. · Source: www.tech-otaku.com

    Check DNSSEC if you recently switched providers

    If you moved your DNS to a new provider and DNSSEC was turned on at the registrar, the old signing records may no longer match. Cloudflare’s documentation says that changing nameservers without handling DNSSEC can cause SERVFAIL errors, and then the domain won’t resolve at all. Ask your registrar or DNS provider to check the DS records. Don’t simply switch DNSSEC off without understanding why it fails.

    Why “wait for propagation” is often the wrong answer

    Propagation is real. Kinsta’s DNS docs say nameserver changes may take 24 to 48 hours, and WordPress.com’s support docs say DNS changes usually take a few hours but can take up to 72. But waiting only helps when the new records are correct. If an A record points at the wrong IP, the site stays broken no matter how long you wait.

    Check the authoritative answer with dig first. If the authoritative answer is correct and a few resolvers still return the old one, that is propagation. If it is wrong, fix it. Change one thing at a time. If you keep editing records while you wait, you soon can’t tell which version is live.

    How to change DNS without taking the site down

    The most damaging DNS mistake is also the easiest to avoid. Kinsta warns that switching nameservers before the records exist at the new provider can leave the domain with no DNS records at all. The website, email and everything else on the domain go down together. Do it in this order:

    1. A day or more ahead, lower the TTL on records you plan to change. WooCommerce suggests a low value such as 300 seconds for a migration. A low TTL makes the switch faster, but not instant.
    2. Copy or import every record into the new DNS provider, including MX records for email and any TXT verification records.
    3. Check each record against the old zone and the new host’s values.
    4. Only then change the nameservers at your registrar.
    5. Keep the old host running until both hostnames resolve to the new server from several networks.

    For a store, pick a low-traffic window and take a fresh backup kept off the host on both sides. Some WooCommerce owners say carts and sessions started before the switch can cause checkout problems afterwards. Agencies running many client domains should keep a written record of which provider is authoritative for each one, along with the other checks in our guide to managing multiple WordPress sites.

    What to check once the domain resolves again

    When the site loads from several networks, you are back in WordPress territory. Check the home page, a few inner pages, the login screen and checkout if you run a store. If something is broken now, WordPress.org’s plugin documentation says to find a conflict by deactivating plugins one at a time. That is the right process for this stage. It never fixes DNS.

    If you would rather not chase what is left yourself, SiteSelf takes WordPress fixes requested through chat once the site resolves. Your DNS records stay with your registrar or DNS provider, and SiteSelf doesn’t change them.

    When to stop and get help

    Stop changing records and contact your DNS provider, host or registrar if:

    • You cannot log in to the registrar or the DNS provider. This happens often when a former developer or agency registered the domain in their own name. Recover access through the registrar’s ownership process, and keep the accounts in your business’s name from then on.
    • dig returns SERVFAIL and you recently changed providers. That points to DNSSEC, which the registrar has to fix.
    • The authoritative records match your host’s values and the site still fails everywhere after the propagation window your provider quotes.
    • The site fails only on one carrier, which suggests resolver filtering.

    When you ask for help, include which devices and networks you tested, when the error started, what you changed beforehand, and the output of your dig or nslookup commands. Support can usually go straight to the record that matters.

    Frequently asked questions

    Is DNS_PROBE_FINISHED_BAD_CONFIG the same as DNS_PROBE_FINISHED_NXDOMAIN?

    No, though both are DNS failures. NXDOMAIN usually means the name has no record or doesn’t exist, which is what you see when an A record was deleted. BAD_CONFIG points more toward the DNS setup or resolver the browser used. The scope test in this article works for both.

    Why does only my site fail when other websites load fine?

    Either your domain’s records have a problem, your computer cached an old answer for that domain, a hosts file entry overrides it, or a resolver is filtering that domain. Test from mobile data. If it fails there too, look at the domain’s records.

    Will changing the WordPress Address or Site Address fix it?

    No. Those settings tell WordPress which URL to use for links and redirects. They have nothing to do with DNS. Changing them while the domain doesn’t resolve can lock you out of wp-admin once it does.

    Can a DNS outage hurt my search rankings?

    If the domain fails for everyone, Googlebot can’t reach the site either. A short outage that you fix quickly is far less of a concern than one left for days. Fix resolution first. Asking Google to reindex does not repair DNS.

    Should I leave my computer on 1.1.1.1 or 8.8.8.8 permanently?

    That’s up to you, and if it’s a work machine, your IT policy decides. It is a reasonable workaround for an unreliable provider’s resolver. Just remember it changes how your machine resolves names, not how your visitors do.

    How much does it cost to have someone fix this?

    No reliable figure exists for this specific error. A local fault costs nothing but time. A broken zone usually takes minutes for whoever has access to the right DNS dashboard, which is why getting your account access back matters more than the hourly rate.

  • 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.