Blog

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

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

Which header are you trying to change?

Pick your row before you open anything.

Find out what controls your visible header first

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

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

How to edit the header in a block theme

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

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

How to edit the header in a classic theme

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

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

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

How to edit an Elementor header

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

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

How to add code to the head without touching theme files

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

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

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

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

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

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

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

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

Why the header saved but nothing changed

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

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

How to fix “Cannot modify header information”

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

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

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

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

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

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

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

How to add HTTP response headers

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

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

What a correct result looks like

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

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

When the theme can’t produce the header you want

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

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

Frequently asked questions