Oyeola Journal
New Website Not Showing on Google? A Seven-Step Investigation
New site published but invisible on Google? Diagnose the exact obstacle using crawl rules, real HTML, canonicals, sitemaps and Search Console, without guessing.
· 5 min read · By Oyekunle Olalekan
You launch a website, search its name, and find nothing. It is tempting to assume that Google is ignoring your site or that a developer forgot some mysterious SEO switch. Usually the most productive response is less dramatic: isolate exactly which stage is failing. Search discovery, crawling, rendering and indexing are separate steps. A site can work perfectly in your browser while never appearing in the search results you expect.
During Oyeola Online's search setup, the domain property was verified and a sitemap was submitted. The initial report contained no indexed pages immediately after submission. That did not prove permanent exclusion: it was an early observation, not a long-term outcome. This guide uses that distinction to build a repeatable diagnosis.
Step 1: confirm the exact public URL
Start with a specific page, not a vague site-wide judgement. Copy the published URL into a private browser window. Make sure it loads without a login prompt, returns the expected article or service page, and is not being redirected to a staging site. Test both the www and non-www hosts and note which version your site names as canonical.
A page that exists only behind preview authentication is not a public search result. Neither is a draft stored in a publishing dashboard. Publishing and public accessibility are two different conditions.
Step 2: inspect how robots rules treat the page
Open your robots.txt file and inspect the page's HTML for a meta robots directive. A site can sensibly block /admin or /portal while allowing its public /blog pages. But a mistaken noindex on an article or a site-wide robots rule can defeat your publication plan.
Robots.txt controls crawling behaviour; noindex gives an indexing instruction when the crawler can actually access the page. They are not interchangeable. Do not put the entire blog behind authentication just to hide the editorial workspace.
Step 3: inspect the page's actual HTML
Many websites deliver a minimal HTML shell and populate the useful text later with JavaScript. Google can render JavaScript, but that introduces additional opportunities for content or links to be missed or delayed. For critical pages, check the raw HTML response for a meaningful article title, description, H1 and visible body content.
Our preferred pattern for Oyeola's public journal is a server-rendered article response at /blog/article-slug, backed by a published record. That keeps each article accessible at a stable, shareable address. However, it still needs a healthy database connection; a server-rendered error page is not an article.
Step 4: inspect canonical URLs and duplicate variants
Inspect the canonical link in the HTML. Does it point to the same intended public URL? A page can accidentally declare a preview address as canonical or send Google to an unrelated page. Redirects and canonical hints should tell the same story.
Before creating more pages, resolve any mismatch between /blog, /blog/, /blog.html and the published article path. You want one preferred address for each page, with internal links consistently using it.
Step 5: check the sitemap, not only its submission status
Visit the sitemap URL directly. It should return valid XML with real canonical URLs for content you intend to be found. For a database-driven journal, verify that published articles appear and draft, rejected and deleted articles do not.
A sitemap receipt only means the discovery request was accepted. It does not mean every page has been crawled, considered useful or added to the index. Compare the number of published articles in your database with the URLs emitted by the blog sitemap.
Step 6: use Search Console's URL Inspection report
Enter the exact preferred URL into Google Search Console's URL Inspection tool. Record its indexing state, Google-selected canonical, last crawl details when available, and any explicit reason for exclusion. If you have just launched, some reports may not yet contain enough data to draw conclusions.
| Observation | What it tells you | What to inspect next |
|---|---|---|
| URL is not known to Google | The page may not have been discovered | Internal links and sitemap |
| Crawled but not indexed | Google fetched the page without adding it to the index | Quality, uniqueness and duplicate signals |
| Blocked by robots or noindex | A technical directive interferes with discovery/indexing | Robots configuration and HTML |
| Alternate canonical selected | Google prefers another version | Redirects, canonical and linking |
| Indexed but no impressions | The page is eligible but not yet showing for queries | Search intent, topic fit and competition |
Step 7: fix the real cause, then measure over time
If the page is blocked, fix the block. If an incorrect canonical is declared, correct it. If the article is just a shallow repetition of what is already online, improve the substance rather than publishing ten more near-identical pages. Add internal links from relevant public pages. Then allow search reporting to accumulate enough data for a meaningful comparison.
Do not diagnose from a single 'site:' search alone. It can be useful for an informal check, but Search Console is better for inspecting the status of a particular URL. Even an indexed page may receive no impressions for a period; that is a separate content-discovery and ranking question.
A practical two-week record
- Day 0: save the canonical public URL, HTTP response, sitemap entry, robots rules, title and unique summary.
- Day 2–3: inspect the URL in Search Console, documenting any issues rather than expecting instant traffic.
- Day 7: verify internal links, inspect indexing again only if a real change was made, and record impressions if available.
- Day 14: compare what changed. Distinguish indexability fixes from content-position improvements.
An empty search report is a question to investigate, not permission to invent a ranking success story.
How this applies to the Oyeola journal
The journal's public pages, sitemap, database and hosting configuration must all tell the same story. Before we announce new articles, we will confirm they are published in the correct environment, render full HTML at their public URLs and appear in the blog sitemap. We will then track impressions as Google begins reporting them.
Primary reference: Google Search Central's developer guide at developers.google.com/search/docs/fundamentals/get-started-developers and JavaScript SEO guidance at developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics. Both distinguish a browser-visible page from information a crawler can discover and process.