If your website is not showing on Google, first establish whether the missing page is in Google's index. A page may be too new, blocked from crawling, excluded by a setting, or affected by a technical error. But an indexed page can also be absent from the results you are checking because it does not rank for that search. Those situations need different responses.
This guide covers ten technical possibilities and what to check before changing anything. They are diagnostic starting points, not ten faults every website has. Start with the exact service, product or homepage URL that matters to your business.
First: is your page missing, or just not ranking?
Open Google Search Console for your website and paste the full page address into URL Inspection. Check the indexed result first, then use the live test if you need to check the current page. A successful live test does not mean that Google has already indexed the page.
- The URL is indexed: investigate visibility for particular searches rather than assuming a crawling failure. Indexing alone does not guarantee an appearance for your chosen phrase.
- The URL is not indexed: read the stated reason. An intentional redirect or duplicate exclusion may be correct; a blocked service page may need a fix.
- You do not have access: ask the account owner or developer for the URL Inspection result and crawl date. Do not treat a missing result in your own search as a complete diagnosis.
For example, a plumbing firm's homepage might appear for its business name but not for "emergency plumber Bristol". That does not, by itself, demonstrate a technical indexing problem. A missing Google Maps listing is also a different question from a missing website page; this guide focuses on website results.
10 technical reasons to investigate
1. Google has not crawled your new page yet
A newly launched website does not appear in search simply because it is live. Google needs to discover and fetch its pages. This can also affect a new service page on an established site.
Check: the URL Inspection result, whether a crawl is recorded, and whether the page is linked from your site and included in its sitemap. If Google already knows the URL, adding it to the sitemap again does not diagnose why it remains unindexed.
Next step: make the public page discoverable and accessible, then request indexing where appropriate. Google says crawling can take days or weeks, and repeated requests do not make it faster. There is no guaranteed indexing deadline.
2. A noindex instruction is excluding the page
A launch or SEO-plugin setting can leave a public page carrying a noindex instruction. This tells supporting search engines not to include it in their index. The instruction may be in the page's HTML or an HTTP response header, so checking the visible text is not enough.
Check: the indexing permission reported for that URL, the robots meta tag and any X-Robots-Tag header. Ask your developer which CMS, template or hosting setting produces the instruction.
Next step: remove an accidental exclusion from pages intended for search, then verify the live response. Keep intentional exclusions on pages that should remain outside search. Google must be able to crawl a page to read its noindex instruction.
3. Your robots.txt file blocks the relevant pages
Robots.txt gives crawlers access rules. A rule copied from a development site can block an entire site or the folder containing your services.
Check: whether the rule applies to the exact missing URL and to Googlebot. Read the reported crawl restriction alongside the file itself; a rule covering an unrelated folder is not evidence of the cause.
Next step: correct the unintended restriction. Do not assume that blocking crawling reliably removes a page from search: Google may still show the URL without its content. This distinction is explained in Google's technical requirements.
4. A login or security challenge prevents access
The site may work for you because you are logged in, while a visitor or crawler receives a password screen, access-denied response or challenge. That can happen when launch protection remains enabled or a firewall rule also catches legitimate crawlers.
Check: the public page in a signed-out browser, then the reported page-fetch result. Ask your hosting provider to investigate relevant access logs if Google cannot fetch it. Your own successful visit does not establish what Google received.
Next step: make the intended marketing pages publicly accessible and correct the specific rule responsible. Private account areas should stay protected; disabling the site's security controls wholesale is not a sensible SEO fix.
5. Your server fails when Google requests the page
Intermittent hosting failures can be easy to miss if you happen to visit when the site is working. Server errors or connection failures can prevent a crawler from receiving the page, even when the address is correct.
Check: the failed URL, response status and time of the failure. Compare Search Console's fetch information with hosting logs and uptime records. A single successful retest does not explain a recurring error.
Next step: ask the developer or host to resolve the demonstrated failure and confirm stable responses. Google's HTTP status documentation explains why a successful response and a server error have different consequences for crawling. An isolated outage does not prove that Google has removed the whole site.
6. The page returns a 404, or looks like an error page
A page that was renamed or accidentally removed may return a 404 status. A different problem is a soft 404: the server reports success, but Google treats the page as missing or effectively empty. An error template or a failed content load deserves investigation in that situation.
Check: the exact address, its HTTP response and the content actually delivered. Google's Page indexing report explains these exclusion reasons.
Next step: restore an accidentally missing page, repair its content delivery, or redirect a moved page to its relevant replacement. A deliberate 404 for removed content with no replacement is normal; do not redirect every missing URL to your homepage.
7. A redirect sends Google to the wrong destination
Following a redesign, an old service address might redirect to an unrelated page, an obsolete domain or a loop. Alternatively, the redirect may work correctly and you are searching for an old URL that is no longer the preferred destination.
Check: the full redirect journey and the final page, not just whether the first URL loads something. Compare the destination with the service the old page described.
Next step: fix incorrect mappings and loops, then update internal links to the intended destination. For a permanent move, Google's redirect guidance recommends a permanent server-side redirect where possible. Changing a temporary redirect without understanding its purpose is not a universal fix.
8. Google is treating another URL as the main version
Duplicate or very similar pages can be grouped under one canonical URL: the version Google selects to represent them. The other addresses may correctly be absent from results. A mistake arises when your website points an important page at the wrong canonical, or sends conflicting signals.
Check: the declared canonical, Google's selected canonical where available, and whether links and sitemap entries point to the intended version.
Next step: correct misleading signals and investigate unintended duplication. Do not force every URL to be indexed when they represent the same content. Google's canonical guidance makes clear that your declared preference influences selection rather than controlling it.
9. The page has no useful internal links
A service page can be published in your CMS without being connected to navigation or any other page. People may only reach it if they already know the address. This makes discovery harder; it does not prove that Google has never found it elsewhere.
Check: whether you can follow ordinary links to the page from relevant parts of the site. A clickable-looking element that relies entirely on a script may not provide a crawlable link.
Next step: add a descriptive link from the appropriate service hub, navigation or related article. Include the canonical URL in the sitemap where appropriate. The aim is a useful route for readers as well as crawlers, rather than inserting unrelated links everywhere.
10. Essential content is missing from the rendered page
A JavaScript failure can leave Google with an empty page shell instead of your service description. A mobile template can also omit information available on desktop, or fetch it only after someone clicks a button.
Check: the rendered HTML and screenshot from a live inspection, alongside a phone-sized browser view. Look for the actual heading, service details and links. A desktop screenshot from your developer is not enough to establish what the crawler received.
Next step: repair failed content loading and make essential information available without requiring interaction to fetch it. Google can render JavaScript, but its JavaScript guidance describes access and rendering constraints. Its mobile-first guidance also calls for equivalent primary content on mobile.
What if the page is indexed but still not showing?
Move from an indexing investigation to a visibility investigation. In Search Console's Performance report, inspect the page's impressions and queries, taking account of country, device and date range. This can reveal appearances you do not see in your own search. Check whether the page genuinely answers the query you want to appear for.
If Search Console shows that a page was crawled but is not currently indexed, that status alone does not identify a technical defect. Review the delivered content and whether it duplicates another page before choosing a fix. Google's indexing report guidance distinguishes these situations. For a sudden disappearance, also review any Manual Actions or Security Issues reported in the account.
Do not buy a speed upgrade, add schema or rewrite every title solely because your own search did not return the page. Each change needs a reason connected to the evidence. Technical eligibility is one part of visibility, and no audit can guarantee a particular ranking.
What should you do after finding a problem?
Record the affected URL, the evidence and the change made. Retest the live page, confirm that important links still work, and request indexing if appropriate. Then allow time for Google's data to update; repeatedly submitting the same URL is not a substitute for fixing the cause.
If several checks point to different issues, read our Technical SEO Audit guide. It explains the scope of a structured review, what a useful findings report should contain and how to separate urgent fixes from lower-priority improvements.
The next commercial step depends on what you already know: OkamiSec's SEO Audit starts from £250 for findings and a prioritised roadmap, while Technical SEO implementation starts from £600 for agreed fixes. The guide explains that distinction and links to the current offers. If you need an initial view before choosing a paid service, request a free Website Intelligence Assessment.