Blog

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:

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.

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.

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

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.

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.

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.

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.

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

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

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

Which checks give you the real answer?

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

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

How to find the version in the WordPress dashboard

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

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

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

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

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

How to read the version from the server

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

With WP-CLI

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

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

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

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

From wp-includes/version.php

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

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

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

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

Checking that the files are what the number claims

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

What a public check can and cannot tell you

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

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

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

Why two tools report different versions

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

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

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

Should you hide the version once you know it?

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

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

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

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

What to do with the number

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

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

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

Frequently asked questions

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

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

Which gallery system is your page actually using?

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

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

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

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

1. Open the page in the block editor and select the whole Gallery block, not one image inside it. If you keep landing on a single image, open List View and click the Gallery row.
2. Click the link icon in the block toolbar and choose Enlarge on click. Some sources call it Expand on click, so use whatever label your version shows.
3. For a single image, select the Image block, open Link and choose the same option.
4. Save or update the page.
5. Open the live page in a private window and click a thumbnail.

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

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

When a gallery plugin earns its place

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

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

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

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

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

WooCommerce product galleries follow their own rules

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

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

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

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

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

Two lightboxes are handling the same click

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

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

Script optimisation ran the lightbox too early

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

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

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

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

The link setting is wrong for the lightbox you use

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

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

The lightbox cannot attach to the gallery’s markup

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

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

A cache is still serving the old page

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

It fails only on phones

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

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

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

Isolate it when none of the above is obvious

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

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

Check keyboard and search behaviour before you call it done

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

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

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

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

Frequently asked questions

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

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

Which WordPress do you actually need?

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

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

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

What does it cost to start a WordPress blog?

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

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

How to set up the blog, step by step

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

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

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

Why the blog page ignores the design you gave it

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

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

Why a published post is not showing in Google

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

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

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

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

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

“There has been a critical error on this website”

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

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

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

“Error establishing a database connection”

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

The homepage works but every post returns 404

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

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

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

When to stop and get help

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

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

Frequently asked questions