If your new WordPress site is not showing in Google, start with one important page and find out where the process stops. A page can be available to visitors, accessible to Google’s crawler and still absent from the index. It can also be indexed without appearing prominently for the phrase you searched.
These five checks help you identify the next useful action without repeatedly changing settings or submitting the same address. They are a documentation-based workflow, not a hands-on test of your website.
Before you start
This guide covers a public, self-hosted WordPress.org installation using the standard WordPress dashboard, including the current 7.1 series. WordPress.com is a hosted service with its own visibility controls; use its platform-specific instructions instead of assuming every menu matches.
You need permission to change WordPress settings, the exact public page address and access to the matching Google Search Console property. Requesting indexing requires owner or full-user access. Ask your host for help if a server setting is involved. Keep a note of each change and its time so that you can distinguish a current result from an older report.
1. Check what an ordinary visitor can open
Open the full page address in a private browser window while signed out of WordPress. Try the home page and one published page that matters to customers. Record the final address if the browser redirects.
You should see the intended content without signing in. If you reach a password screen, an unfinished holding page or an error, resolve that access problem before working on search settings. Only remove a launch restriction when the site is ready for public access. Keep staging copies and private material protected.
This simple test establishes a visitor baseline; it does not prove that Google can fetch the same page. Google’s missing-page troubleshooting guide identifies access restrictions and discovery problems among the issues to investigate.
2. Review WordPress search visibility
In the standard dashboard, open Settings → Reading and find Search Engine Visibility. For a public site that you want indexed, clear the option labelled Discourage search engines from indexing this site, then save your changes.
Reopen the screen to confirm the saved setting. WordPress documents this control as a request to search engines, not a password or access barrier. Leaving it enabled does not make confidential material private.
If the box was already clear, do not keep toggling it. Move on to the individual page: the dashboard setting alone cannot establish what Google actually receives.
3. Look for a remaining noindex instruction
A noindex instruction tells a supporting search engine to exclude a page after reading it. Google supports it in an HTML meta tag or an HTTP response header called X-Robots-Tag. Its noindex documentation explains both methods.
Inspect the affected page’s search visibility setting in your SEO plugin, if one is installed. Menu names vary, so consult that plugin’s documentation. If an exclusion is unintended, change the setting that produces it rather than editing a generated page. Ask your host to check response headers if the exclusion persists.
Do not add noindex to robots.txt: Google does not support it there. Blocking crawling can also prevent Google from seeing a page’s noindex instruction. These controls solve different problems.
Keep exclusions that are intentional. For an uncertain technical change, establish a recovery route first; Nevelit’s WordPress backup restore guide explains how to check that a backup is usable.
4. Compare Google’s stored result with a live test
In Search Console, select the correct property and paste the complete page address into URL Inspection. Read the indexing explanation and note the crawl date. Then run the live test to examine the current page.
Google distinguishes the indexed result from the live test. A correction made today may not yet appear in the stored result. Search Engine Land’s practical URL Inspection guide also explains how to compare the two views and examine crawl dates, indexing rules, canonical choices and rendered HTML. Where available, inspect the tested page’s HTML and response information to check whether the unwanted rule remains.
A successful live test is useful evidence, but it does not guarantee indexing or rankings. It does not cover every quality, security or removal condition. If Google has selected a different canonical address, inspect that address too: “canonical” means the version Google treats as the representative page. The live test cannot predict that selection.
5. Request a crawl after correcting the cause
Once the relevant problem is fixed, use Request indexing for the important page. For a new site with several pages, check whether your platform or SEO plugin already supplies a sitemap and submit the appropriate sitemap through Search Console. A sitemap helps discovery; it is not proof that its pages are indexed.
Google’s recrawl guidance says crawling can take days to weeks and that repeated requests do not make the same URL get crawled faster. Submission does not guarantee inclusion.
Record the request date and return to URL Inspection to check for a later crawl and an updated indexing result. Search Engine Land likewise notes that repeated requests do not speed up crawling and that indexing is never guaranteed. If the page remains excluded, follow the reported reason. If it is indexed but attracts few visitors, investigate its usefulness and the searches it answers instead of assuming another visibility toggle will help.
For a small business, the practical aim is a clear diagnosis: which page is affected, what Google last saw, what changed and what evidence would confirm progress. That record makes a request to your host or developer far more useful than “my site is missing”.
Leave a Reply