You launch a fresh WordPress install. You create a test post. You click “View Post” — and the screen stares back with a blank, gray “Nothing Found.” No error codes, no stack traces, just that quiet, design-less void. For a systems engineer who builds sites from the ground up, this moment is equal parts irritating and telling: something in the stack isn’t resolving requests the way WordPress expects. The fix is almost never inside the content itself. It’s in the wiring.
I’m Jonas Venn, and on jooomshaper.com I work through the structural layer of WordPress — how requests flow from the web server through PHP, how rewrite rules turn pretty permalinks into query variables, and why a misstep in any of those layers produces exactly this symptom. This article walks through the first three things to check, in order, when a new WordPress site returns “Nothing Found.” No guesswork. No generic advice. Just the technical sequence that resolves the problem in the majority of cases.
Check One: Permalink Structure and Rewrite Flush
WordPress serves content by translating a URL like /hello-world into an internal query that looks something like ?p=1. That translation happens through a set of rewrite rules stored in the database. On a brand-new install, those rules might be empty, stale, or misconfigured — especially if the site was set up via a script, a migration, or a one-click installer that didn’t complete the standard post-installation flush.
The symptom is predictable: you can see posts in the admin list, they’re published and public, but visiting their permalink returns “Nothing Found.” Meanwhile, the default plain permalink structure — ?p=123 — works fine when you type it directly in the browser. That tells you the content exists; the rewrite engine just isn’t mapping the pretty URL to it.
Step-by-Step Diagnosis
Start in the admin panel under Settings → Permalinks. If the selected option is “Plain,” switch it to “Post name” (the most common choice for clean URLs) and click Save Changes. WordPress will call flush_rewrite_rules() behind the scenes, rebuild the rewrite array, and update the .htaccess file on Apache servers or the internal rewrite store on Nginx. Don’t just save without changing; the act of selecting something and hitting save triggers the flush. If it’s already set to “Post name,” select “Plain,” save, then select “Post name” again and save. This forces a full rebuild.
After saving, visit a post’s permalink. If “Nothing Found” disappears, you’ve solved it in under a minute. If it persists, the issue sits deeper — likely in the web server configuration or a plugin that’s intercepting the query before WordPress can process it.
When Rewrite Flush Isn’t Enough
Some managed hosting environments and custom Docker setups cache rewrite rules aggressively. If you’re using an object cache like Redis or Memcached, the flush might not propagate immediately. Run wp rewrite flush from WP-CLI if you have shell access; it bypasses the admin UI and directly resets the rules. For sites without WP-CLI, adding $wp_rewrite->flush_rules(); temporarily to a theme’s functions.php (and removing it afterward) achieves the same effect. But approach that cautiously — you’re touching the theme file, and a syntax error there can lock you out of the admin.
Check Two: Web Server Rewrite Rules
If the permalink structure is correct and the rewrite flush didn’t help, the next stop is the web server. WordPress relies on the server to pass requests through a single entry point — index.php — with the original request URI intact. When that mechanism breaks, WordPress receives a mangled or empty request and can’t map it to any post, page, or archive. The result is the same “Nothing Found” message, but the cause is now a configuration issue, not a database issue.
Apache: The .htaccess File
On Apache, look inside the site’s root directory for .htaccess. A standard WordPress block looks like this:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressIf the file is missing entirely, WordPress can’t write it — often because the file system permissions won’t allow it. Create it manually with the block above, making sure the file is readable by the web server user. If the file exists but the rules are different, a security plugin or a previous developer may have modified them. Restore the default block, then flush permalinks again from the admin.
Also check that Apache’s mod_rewrite module is enabled. On Ubuntu or Debian, sudo a2enmod rewrite followed by sudo systemctl restart apache2 activates it. Without that module, the .htaccess file is ignored, and pretty permalinks simply won’t work.
Nginx: Try Files and Location Blocks
Nginx doesn’t use .htaccess. Instead, the site’s server block must include a directive that sends all non-static-file requests to index.php. The standard configuration looks like this:
location / {
try_files $uri $uri/ /index.php?$args;
}If your Nginx config uses an older or incomplete pattern — like try_files $uri $uri/ =404; — WordPress will never receive the request for a pretty permalink, and “Nothing Found” will appear. Edit the server block, test with nginx -t, and reload Nginx. In some setups, the location ~ \.php$ block also needs to include fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; and other standard FastCGI parameters. A missing PATH_INFO parameter can cause similar symptoms on certain PHP configurations.
After adjusting the server config, flush permalinks once more. The combination of correct rewrite rules in WordPress and a correct server setup almost always resolves the issue at this stage.
Check Three: Query Interference and Home URL Mismatches
If the permalink structure is flushed and the server rules are verified, the problem is likely in how WordPress interprets the request. Two common culprits stand out: a plugin (or theme function) that modifies the main query through pre_get_posts incorrectly, and a mismatch between the WordPress Address (URL) and Site Address (URL) settings.
The pre_get_posts Trap
Developers use the pre_get_posts action to alter the default query — for example, to change the number of posts shown on an archive page or to exclude a category from the home page. But if the action doesn’t check is_main_query() or applies conditions that accidentally affect single post requests, it can wipe out the query’s ability to find a post. The function might set a meta query that returns zero results, or it might alter the post type parameter so that the requested post type is excluded. The result is “Nothing Found” on every single post, while pages and archives work normally. I’ve wasted an afternoon on this exact scenario. You start doubting the database, the server, your career choices — and it’s just an overeager callback in a forgotten plugin.
To test, temporarily switch to a default theme (Twenty Twenty-Four or similar) and deactivate all plugins. If the problem disappears, reactivate them one by one until it returns. When you find the offending plugin, look at its pre_get_posts callback. The fix is often a simple conditional: if ( ! is_admin() && $query->is_main_query() && $query->is_home() ) — the key being that it only runs on the specific query you intend to modify, not on every query across the site.
Home and Site URL Mismatch
Under Settings → General, two fields define the site’s address. If the “WordPress Address (URL)” points to a different domain or subdirectory than the “Site Address (URL),” and the server isn’t configured to handle that split, WordPress may generate permalinks that don’t match the request path. For example, if WordPress is installed in a subdirectory but the site address is set to the root domain, the rewrite rules might expect a prefix that isn’t present in the actual URL. The query fails to find the post, and “Nothing Found” appears.
Verify that both URLs are correct and that the site is accessible at the address you expect. If you need to change them, do it through the admin UI if you can still access it, or directly in the wp_options table (siteurl and home rows) if you can’t. After changing, flush permalinks one more time.
When It’s Not a Standard Install
Some setups introduce variables that break the usual debugging sequence. Multisite networks, Bedrock-style directory structures, and Composer-based installations all move core files away from the web root. In these cases, the .htaccess or Nginx config must point to the correct index.php location. A Bedrock site, for instance, expects the web root to be /web, not the project root. If the server block points to the wrong directory, WordPress never loads, and the request falls through to a 404 handler that displays “Nothing Found” from the theme’s index template.
Similarly, sites behind reverse proxies or load balancers can lose the original request URI. If the proxy forwards requests without setting the X-Forwarded-Host or X-Forwarded-Proto headers, WordPress may reconstruct the URL incorrectly. In wp-config.php, adding explicit definitions for WP_HOME and WP_SITEURL — and sometimes adjusting $_SERVER['HTTPS'] — gives WordPress the information it needs to build correct permalinks and process the query.
Why the Order Matters
I’ve watched developers jump straight to database repair plugins or core file replacements when a site says “Nothing Found.” That’s like rebuilding an engine because the car won’t start, without checking the battery first. The permalink structure and rewrite flush are the fastest, least invasive checks — they solve the problem in under a minute for a large chunk of new sites. Server rewrite rules come next because they’re the transport layer: if the request never reaches WordPress in a recognizable form, no amount of admin tweaking will help. Query interference and URL mismatches are the third tier because they’re more layered and require understanding how a specific plugin or configuration alters the default behavior. Skip the order, and you’ll burn hours chasing ghosts.
Following this sequence keeps you grounded in the request lifecycle. It turns a vague, frustrating error into a straightforward debugging path that respects the architecture you’ve built.
FAQ
Why does “Nothing Found” appear only on custom post types?
Custom post types need their rewrite rules registered before the permalink flush. If you registered the post type in a plugin or theme’s functions.php but forgot to flush permalinks afterward, WordPress doesn’t know how to route those post type URLs. Go to Settings → Permalinks and click Save Changes to rebuild the rules. If the post type uses a custom slug or archive, confirm that the has_archive and rewrite arguments are set correctly in the registration code.
Can a caching plugin cause the “Nothing Found” message?
Yes, especially if the cache holds a stale page where the content wasn’t yet published or the rewrite rules changed after the cache was generated. Clear the cache from the plugin’s settings and disable the plugin temporarily to see if the issue resolves. Some object caching systems also store rewrite rules; if you’re using Redis or Memcached, flush the object cache after changing permalink settings.
What if my site uses a static front page and the blog page says “Nothing Found”?
This usually happens when the “Posts page” setting under Settings → Reading points to a page that doesn’t exist or was deleted. WordPress tries to load that page as the blog archive, but without a valid page object, the query returns no results. Check the reading settings and make sure the selected posts page is published and not in the trash. If you don’t need a separate blog page, set “Posts page” to “— Select —” and rely on the default archive behavior.