If your page does not show up on Google, it is almost always one of four reasons: it is not indexed, it does not answer what people search, it loads too slowly, or it competes for the wrong words.
The difference between the four matters, because the work that fixes each one is different and the order is not neutral. This note separates them using the thresholds Google itself publishes, so the diagnosis does not rest on the opinion of whoever runs it.
01
Is it even indexed?
That is the first thing to check, because if the search engine has no record of the page, nothing else you do will move it. Searching your domain preceded by site: gives a first signal in ten seconds.
A page existing does not oblige Google to include it. Its official documentation describes Search in three stages — crawling, indexing and serving — and is explicit: indexing isn't guaranteed, and not every page Google processes will be indexed. Following the guidelines improves the odds; it does not secure them.
There are four typical reasons a page is not indexed, and all of them are fixable:
- The site blocks crawlers, through robots.txt or a noindex tag left over from the development stage.
- There is no sitemap, or the one there points at addresses that no longer exist.
- Canonical tags are misconfigured and tell Google the real page is a different one.
- The site is recent and was never submitted to Search Console, so Google does not know it exists yet.
02
What exactly does Search Console mean?
Search Console does not only say whether a page is in or out: it says where in the process it stopped. That distinction is what turns a complaint into a diagnosis.
The two states that cause the most confusion are defined by Google in the page indexing report. "Crawled - currently not indexed" means the page was crawled by Google but not indexed, it may or may not be indexed in the future, and there is no need to resubmit the URL. "Discovered - currently not indexed" means Google found it but has not crawled it yet, typically because doing so was expected to overload the site, so the crawl was rescheduled.
The practical reading differs in each case. If it says crawled and not indexed, Google saw the page and decided it added nothing: the work is editorial. If it says discovered and not crawled, the issue is usually server capacity or URL volume: the work is technical.
Resubmitting the URL over and over changes neither. Google says so in as many words for the first case, and it is the most common mistake made by owners managing their own site.
There is a third state worth checking even though it confuses nobody: pages excluded by a noindex tag. These often survive from the development stage and nobody removes them at launch, and in that case the site is explicitly asking Google not to show it.
03
How long does it take to load, and against what number?
Against three public thresholds, not against an impression. Speed affects ranking and affects sales, and it has been measured for years with defined metrics and concrete values.
Google's Core Web Vitals set three: the main content should paint in 2.5 seconds or less (LCP), a response to an interaction should take 200 milliseconds or less (INP), and unexpected content shift should stay at 0.1 or less (CLS). They are assessed at the 75th percentile of real page loads, segmented across mobile and desktop.
The 75th percentile is the part that usually gets overlooked. It is not enough for the site to be fast on the machine of whoever built it: it has to be fast for three out of four real visits, and most of those visits are mobile and on worse networks than an office.
The common causes of failing those numbers are well known: unoptimised images, templates loaded with features nobody uses, and cheap hosting that responds slowly under any concurrency.
It is worth measuring with field data rather than lab data. A one-off test from a fast connection tells you how the site loaded that time; the 75th percentile tells you how it loads for the people who actually visit, which is what Google uses. The two numbers can differ considerably, and the second is the one that counts.
| Metric | What it measures | "Good" threshold |
|---|---|---|
| LCP | How long the main content takes to paint | 2.5 seconds or less |
| INP | How long the site takes to respond to an interaction | 200 milliseconds or less |
| CLS | How much content shifts while loading | 0.1 or less |
| Percentile | What share of real visits it is assessed on | 75% of page loads |
04
Does it have content that answers what people search?
Many sites describe the company and answer no question at all. If the client types "how much does it cost" or "how does it work" and the site has no page answering that, there is nothing for Google to show.
Showing up does not depend on having more pages, but on having pages that answer what the client actually types, in the vocabulary they use. It is the difference between a section called "Integrated solutions" and one called "What a website costs": the first describes, the second answers.
That is why this note exists, and why, for example, what a website costs in Costa Rica does too: those are the questions people type before hiring, and answering them is what makes a site appear at that moment.
05
What if the site looks great?
It can look impeccable and be invisible. Design is judged by whoever already arrived; the search engine judges structure, content, speed and technical signals. Two different exams.
There are beautiful sites that fail the second, and not through any carelessness by the designer: many of the decisions that make a site striking — large images, animation, heavy typefaces — are exactly the ones that worsen the three numbers above when nobody keeps them in check.
The fix is rarely to make the site plainer. It is to decide, deliberately, what the design spends its performance budget on, and to measure the result rather than assume it.
A site that doesn't show up on Google isn't a storefront: it's a brochure in a drawer.
06
How long does a new page take to appear?
There is no guaranteed timeframe, and anyone promising one is guessing. Google does not publish times because crawling is scheduled against the site's capacity and the number of URLs already queued.
What can be stated is what shortens that wait and what lengthens it, because it follows from how the three-stage process works:
- It is shortened by having the site verified in Search Console and an up-to-date sitemap: that is how you signal the address exists.
- It is shortened by the page being linked from another that is already indexed. A page no link reaches is hard to discover.
- It is lengthened by a slow server, because Google reschedules the crawl to avoid overloading the site — literally what the "discovered, currently not indexed" state describes.
- It is lengthened by thousands of low-value URLs competing for the same crawl queue, such as a catalogue's filters and sort orders.
The practical consequence is that impatience does not help and sometimes hurts. Resubmitting the same URL every day advances nothing; publishing content worth indexing and linking it properly does.
07
Do you fix it or rebuild it?
It depends how deep the problem runs, and an honest answer can be given in a few days. Getting this decision wrong costs months of patching something that was never fixable.
- Fix it when the foundation is sound and configuration is missing: indexing, sitemap, tags, image optimisation and new content.
- Fix it too when the three speed numbers fail for specific causes rather than because of the platform itself.
- Rebuild when the platform is too heavy and no optimisation brings it under the thresholds.
- Rebuild when content is fragmented across languages, has no indexable structure, or nobody has maintained it in years.
That is exactly what was done for a Costa Rican logistics operator: an outdated, unindexed site, dead social channels and zero SEO. You can read how its digital presence was relaunched in 30 days, including the criterion used to decide on rebuilding rather than patching.
08
Where do you start this week?
With three checks that cost nothing and that order everything else. None of them requires hiring anyone.
- Verify the site in Search Console and open the page indexing report. Note how many pages are indexed and what state the rest are in.
- Measure the three Core Web Vitals with field data rather than lab data, and write the three numbers down exactly as they come.
- Write the five questions your clients ask before buying and check whether the site has a page answering each one.
If the site does not answer those five questions, you already know the first job, and it is not technical. If it also fails the three numbers, the work is twofold and the order is worth deciding before starting.
At ZENITAR that diagnosis is delivered in writing before anything is proposed, because the result is measured in the client's operation and not in a report. The technical work comes in through software and web; if the symptom is broader than the site, start with what to check when the company stops growing.
