Why is my website not showing up on Google?
Because of one of three separate problems: Google doesn't have the page, something's stopping Google from keeping it, or Google has it and shows other pages first. Each one has a different fix, and telling them apart is where my crawlability and indexing service starts. This table is the one-screen version of everything below it.
| What you see | First check | Where I look on WordPress | Usual fix |
|---|---|---|---|
| No results at all for a site: search, months after launch | URL Inspection on the homepage | Settings, Reading, then the SEO plugin's indexing settings | Remove the noindex or the block, then request indexing |
| One page is missing while the rest shows | URL Inspection on that page | That page's SEO plugin settings and the live robots.txt | Clear the block on that URL, or fix what Search Console reports |
| Google sees a login or coming soon screen | Open the page in a private window | Maintenance plugins and host password protection | Switch the wall off on the live site |
| The site shows for its name but not its services | Search the name, then a service | Not a setting: the content and the links | Ranking work on intent, content and links |
| The site vanished after a move or redesign | Where the old URLs land now | The redirect plugin or the server rules | Redirect every old URL to its new home |
Is the site indexed at all?
Everything else hangs on this answer, so it comes first. The quick check is a site: search. I type site:yourdomain.com into Google and look at what comes back. No results at all, on a site that's been live for months, points at a block or a discovery problem. Google says the site: operator doesn't necessarily return every indexed URL, so I treat it as a first look, never as the final count.
The real answer comes from the URL Inspection tool in Search Console. For the exact address I paste in, the verdict reads URL is on Google or URL is not on Google, and that's the check I trust. It only inspects URLs inside a property you can open, so a site with no Search Console access gets that set up first. Even a good result has limits: Google says URL is on Google doesn't guarantee the page will appear in results.
Is something blocking Google?
If the page isn't on Google, the next thing I look for is a door that's been shut. Google's help page on missing pages names the usual ones: a robots.txt block, a noindex rule and password protection. On WordPress each has a familiar hiding place, and most take minutes to confirm once you know where to look. The quickest to rule out: check your WordPress robots.txt and read what it disallows.
| Block | What it tells Google | Where I look on WordPress |
|---|---|---|
| A noindex rule | Drop this page from results, even if other sites link to it | Settings, Reading, the Discourage search engines box, then the SEO plugin's settings per page and per post type |
| A robots.txt Disallow | Don't fetch this URL | The live /robots.txt file, a rule left over from staging, and whatever the SEO plugin writes into it |
| An X-Robots-Tag header | The same noindex, sent by the server instead of the page | The response headers, which a caching or security layer can add without it showing in the dashboard |
| A password or login | There's nothing to read without signing in | Maintenance and coming soon plugins, and host level password protection that's still on after launch |
WordPress's own documentation says that since version 5.3 the Discourage search engines box writes a noindex, nofollow robots tag into every page. It's meant for a site that isn't ready yet, and it's easy to forget once the site is.
The order of the checks matters. Google says a noindex only works if Google can fetch the page, so a page blocked in robots.txt never shows Google its noindex, and it can still appear in results if other sites link to it.
I read all of this in the page source and the response headers, not the dashboard, because a setting can say one thing while the page sends another.
Not on WordPress? Site builders hide the same switch somewhere else. Squarespace's help centre says search engines won't find trial, expired or canceled sites, and that a page's SEO tab shouldn't have Hide this page from search results ticked. Wix keeps a toggle called Let search engines index your site in its SEO settings. Find the switch, then inspect the URL.
Blocking a page in robots.txt to get it out of Google is the move that backfires. Google can't read a noindex it isn't allowed to fetch, so the URL can linger in results. Let the page be crawled and send the noindex instead.
Rather have me do this? One person, whole job.
Book a call on UpworkHow does a brand new website get on Google?
Mostly on its own, so there may be nothing wrong yet. Google's getting started page says it automatically looks for sites to add, and that it can take a few weeks for Google to notice a new site. So a site that went live on Monday and isn't in results by Friday isn't a fault, and I won't put a date on when it'll appear.
Getting Google to index a new site is mostly about giving it a way to find it. Google lists a site that isn't linked to by other sites as one of the reasons it gets missed. So I verify the domain in Search Console, submit the sitemap the SEO plugin already builds, and link the pages that matter from the homepage and the menu. Links from other sites help too, earned the right way: a supplier's stockist list, a trade association, a real partner. Google warns against paying for links.
Indexed but not ranking: what does that mean?
It means Google has the page and is choosing other pages over it for the searches you tried. First I search for the business by its own name. If the site shows for that, Google's willing to show it. If it doesn't, I look for something bigger.
The Manual actions report shows a green check mark when there's nothing to report. Anything else means a human reviewer at Google found pages that break its spam policies, which is Google penalty recovery work. The Security issues report covers hacked content. And if the site vanished after a platform or domain move, the redirects are the first suspect. With those ruled out, it's one of these five.
- i.
Thin or duplicate pages
When several pages say nearly the same thing, Google shows one. Its canonicalization guide says that if you don't specify a canonical URL, Google will identify which version is objectively the best one to show in Search. A thin page that repeats a stronger one loses, so I merge it, rewrite it or canonicalize it.
- ii.
The page answers a different search
Google's own explanation of ranking says the most basic sign of relevance is content that contains the same keywords as the search. Words aren't enough, though. If the top results are guides and the page is a sales pitch, or the other way round, it's answering a question nobody asked in that search. The fix is the page, not a setting.
- iii.
Few other sites link to it
Google says one of the factors it uses to judge quality is whether other prominent websites link or refer to the content. A new site with no links isn't broken. It just hasn't earned that signal yet, and the honest route is the links a real business already has a right to, never bought ones.
- iv.
A core update moved it
Google says core updates are designed to present helpful and reliable results, and that pages which move down aren't necessarily bad, since other pages simply made the list. It also says recovery can take several months. A drop that lines up with an update date is a content question, not a penalty, unless Manual actions says otherwise.
- v.
It's slow or broken on a phone
Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking. A page that hides text, drops its menu or breaks on a phone is judged on that version. I test the key pages on a phone and in URL Inspection's live test before I blame anything else.
How I triage a website that isn't showing up on Google, step by step
Each step rules something out, so a later check only runs once the ones before it come back clean.
- Step 01
Run a site: search
Zero results on an established site sends me straight to the robots.txt and noindex checks.
- Step 02
Inspect the pages that matter
URL Inspection on the homepage and one money page, with the reason Search Console gives for any that aren't on Google.
- Step 03
Read the live robots.txt
I look for a Disallow that covers the pages, especially a blanket one left behind from staging.
- Step 04
Check for noindex in the source and headers
The robots meta tag in the source, the
X-Robots-Tagheader, then the settings behind them. - Step 05
Look for a login wall or an error
A coming soon plugin, a host password or a firewall rule can hand Google a login page, a 401 or a 403 where the content should be.
- Step 06
Check how Google could find it
The sitemap's submitted, and the page is linked from the menu or the homepage.
- Step 07
Search the name, then the service
Showing for its name but not its services means a ranking question, not a block.
- Step 08
Open Manual actions and Security issues
Two reports, a minute each, that rule out the rare causes before I spend time on content.
If you'd rather hand the whole triage to one person, from the first site: search to the fix for whatever it finds, that's the indexing work I do. It's remote, and all I need to start is read access to Search Console.
Book a call on UpworkWhen does the Page indexing report take over?
Once the site's indexed in general and the question becomes which pages aren't. The Page indexing report gives a reason for each URL Google knows about but hasn't indexed. Google says a site with fewer than 500 pages probably doesn't need it. On a bigger WordPress site, with archives, products and attachments, it's where I start.
Read it with one rule in mind: Google says you shouldn't expect every URL to be indexed, only the canonical pages. A redirect or a noindexed tag archive in there is the report working as it should. So are duplicate URLs without a canonical, as long as Google kept the right one.
Two statuses bring most people to that report: Discovered and Crawled, currently not indexed. They aren't blocks. When the triage above comes back clean but key pages still aren't in, I send people to the guide that works through both of those statuses.
