A new WordPress page can be published, linked from the menu and visible in your browser while you still have no evidence that Google has visited it. To diagnose that gap, follow the URL through the site rather than changing several plugins at once.
Quick Answer
Google needs a discoverable URL and access to the page before it can retrieve the content. Internal links, sitemap entries, server responses and rendering each affect a different part of that process. A working browser visit confirms your own session; a recorded Google crawl needs separate evidence.
Trace One Real Route Through the Site
On 19 September 2026, SeoNative’s homepage linked to its Start Here page from the header, the main content and the footer. Its four topic cards pointed to sections of that same guide. Those are concrete routes a visitor can follow before any blog posts are published.
The WordPress section uses /start-here/#wordpress, while the technical section uses /start-here/#technical. These fragments identify sections of one document. They are not four separate articles. Counting those links as four new content pages would overstate what the site contains.
Google recommends ordinary anchor links with usable href destinations. This also gives you a practical test: the link should expose the actual destination, not depend only on an unrelated element’s click handler. Google’s crawlable-link guidance.
A Sitemap Adds a Discovery Route
A sitemap is another way to make URLs discoverable. It is especially useful when links alone give a new site limited exposure. Listing a URL still does not guarantee that Google will crawl or index it. Google’s sitemap overview.
Find the sitemap your own installation produces before referring to it in a checklist. Record its exact address and check whether the page you care about appears there. Do not assume that every WordPress site uses the same sitemap path, or that an SEO plugin’s presence proves a specific file is working.
Our initial SeoNative inspection did not verify the sitemap contents. The reader used for that check could not retrieve the candidate file. That leaves a gap in the evidence; it does not establish a sitemap fault.
Fetching and Rendering Can Reveal Different Problems
Google’s JavaScript guidance separates crawling, rendering and indexing. Content already present in the HTML response is available during initial processing; pages that rely on scripts may need rendering to expose their content. Blocked pages or resources can interfere with that work. Google’s JavaScript SEO basics.
For a WordPress site, identify what the reader sees before interacting. An introduction and its section links should be easy to locate. A decorative animation is a different concern from a script that must run before the article text exists.
SeoNative’s homepage selector changes a panel and its destination. The page also supplies separate links to the guide’s four sections. That gives us a useful design review question: does the site still offer a clear route to the content outside an optional interaction? It is a question about the implementation, not proof of Google’s rendering result.
Separate Evidence From Assumptions
| Observation | What You Can Say | What It Does Not Establish |
|---|---|---|
| The page opens signed out | This browser session could view it | Googlebot received the same response |
| A link points to the URL | A discovery route exists | Google has followed that link |
| A sitemap lists the URL | The URL is listed in that file | The page has been indexed |
| A report contains a crawl date | A crawl was recorded for that URL | The page ranks for the target query |
| An access log says Googlebot | A request used that user-agent string | The requester’s identity is verified |
If you use server logs, ask the hosting team to distinguish a claimed bot name from a verified Google crawler. Keep the exact requested URL, time, response and verification method with the record. A screenshot showing only a user-agent name is incomplete evidence.
Use a Small-Site Diagnostic Order
- Choose one important URL and record why it should be public.
- Follow the link to it from a page visitors can already reach.
- Open it signed out and check that the expected article content appears.
- Have the relevant owner check access controls, robots rules and the response for that URL.
- Compare any available crawl record with the time of the last site change.
- Resolve the specific problem found, then repeat the same check.
Start with a missing link or a page-access problem before inventing a crawl-budget explanation for a tiny site. Google’s advanced crawl-budget guide is primarily aimed at large or frequently changing sites, while also covering sites with many discovered-but-unindexed URLs. Its example sizes are rough guidance, not hard limits. Google’s crawl-budget guidance.
What to Keep in Your Log
Record the page address, check time, observed state, change made and next question. Keep “not checked” separate from “failed.” If an inspection tool cannot open a file, record the tool limitation instead of converting it into a claim about Google.
The useful outcome is a traceable explanation: the page has a known discovery route, its access has been checked, and any crawl claim has a dated record. Our technical starting checklist helps keep those checks in order.
Trace One URL From Discovery to Indexing
A useful way to understand crawling is to follow one real page instead of thinking about the whole site at once. Start with a URL you can reach from the main navigation or an internal link. Confirm that the page returns normally, is not blocked by an intentional crawling rule, and links to other useful pages rather than ending as an isolated document.
Then separate discovery, crawling, and indexing in your notes. A search engine can know that a URL exists without crawling it immediately, and crawling a page does not guarantee that it will be indexed. If the URL appears in Search Console, compare the reported state with what the page currently does instead of treating any single label as the entire diagnosis.
For a new WordPress site, this method also helps expose structural issues early: important pages that are buried too deeply, duplicate routes created by configuration, internal links that point to the wrong version of a URL, or thin archive pages competing with stronger guides. Fix the specific path problem you can demonstrate before adding more crawl-related settings.
Watch the Topic in Context
How Google Search Crawls Pages
This official Google Search Central explanation directly complements the article’s walkthrough of URL discovery, Googlebot, fetching, rendering, and sitemaps.
Watch on YouTube ↗ · Google Search Central