Why Your Website Isn't Showing Up on Google

Our own website was invisible to Google for months. Not ranking badly — absent. Typing site:tivadigital.com.au into Google returned nothing at all.

We are a Melbourne digital marketing agency. We run Google Ads accounts, we rebuild tracking, we find the reasons other people's sites underperform in search. And the site with our name on it was not in the index.

We found it on 13 August 2026 and fixed it over two days. There were six causes. Every one was the kind of dull, mechanical fault we check for on client sites as a matter of routine. Not one of them announced itself. Below is each fault, what the symptom looked like, why it survived for months, and the exact check you can run on your own site.

One disclosure before anything else: the fixes landed yesterday and today. As at publication the site has not yet been re-indexed, and I'm not going to claim a result we haven't measured. I'll update this post with the recovery timeline as it happens.

Why isn't my website showing up on Google?

In the sites we've looked at, a site that doesn't appear usually isn't penalised — it's either not indexable, or Google has crawled it and decided it isn't worth indexing. The usual causes are canonical tags pointing at the wrong domain, pages that render empty to a crawler, duplicate titles across every URL, a noindex left over from development, and no Search Console property confirming Google can see the site at all.

The first check, before anything else

Search Google for site: followed by your domain, with no space:

Nothing back means Google has no pages from your site indexed. Two results when you have thirty pages means partial indexing. Everything back means your problem is ranking, not indexing, and this article isn't about your problem.

Ours returned nothing.

Cause 1: Every canonical URL pointed at a staging hostname that returns 404

What it looked like. Every page on the live site carried a canonical tag, an og:url and schema URLs pointing at tiva.tivadigitalco.workers.dev — a staging hostname that returns a 404. A canonical tag is how a page tells Google "the real version of me lives here." Ours were naming an address that does not exist.

Why it silently persisted. The build uses an environment variable, VITE_SITE_URL, to set the public domain. It was never set in the deploy environment, so the code fell back to its default — the staging URL used during development. The build didn't fail. Nothing turned red. Deploys succeeded for months, each one confidently telling Google to ignore the real site in favour of a dead one.

How to check yours. Open your homepage, view the page source (Ctrl+U on Windows, Cmd+Option+U on Mac), and search for canonical. Or from a terminal:

The URL that comes back must be your real, live domain. Check three or four pages, not just the homepage — templates often differ. Then open Google Search Console, run URL Inspection on a page, and compare "User-declared canonical" against "Google-selected canonical". When those disagree, Google has overruled you, and it tells you so.

Cause 2: The pre-render printed a success tick and wrote empty pages

What it looked like. Our site is a React single-page application that pre-renders its pages at build time so crawlers get real HTML instead of an empty shell. The build log showed a tick beside all 13 routes. What it actually wrote were 6KB shells with no h1, no body copy, and no links. In a browser it looked perfect, because the browser ran the JavaScript. To anything reading the raw HTML, the site was blank.

Why it silently persisted. Every route in the app is a React.lazy() import. The rendering function, renderToString, cannot wait for a Suspense boundary to resolve — it emits the loading fallback and returns. It doesn't throw. It doesn't warn. It returns a string, the script writes that string to a file and reports success, because from its point of view it succeeded. The only way to catch it is to look at what was written rather than what was reported.

Why this matters. Google documents JavaScript rendering as a separate, queued stage that happens after crawling, so rendered content can be indexed later than HTML content or not at all (Google Search Central, "Understand the JavaScript SEO basics"). Social preview bots generally don't run JavaScript at all, so a shell page produces a blank preview.

How to check yours.

The test that matters is whether your headline and body text appear in the raw HTML. Use the byte count only to confirm what you've already seen: our homepage was 6,152 bytes with zero h1 elements before the fix and 64,322 bytes after. No terminal needed — View Source (not Inspect Element; Inspect shows the rendered DOM, View Source shows what was sent) and search the page for your headline. If you can't find it, Google wasn't given it either. In Search Console, URL Inspection → Test Live URL → View Crawled Page → HTML shows the same thing from Google's side.

Cause 3: Thirteen pages shipped one title between them

What it looked like. Every page had its own title and meta description written properly in the code. All 13 pages went live carrying the homepage's title and the homepage's canonical. To Google, that's not 13 pages — it's one page and twelve apparent duplicates.

Why it silently persisted. The titles were computed during the pre-render and then thrown away. The build collected the correct metadata for each route and never injected it into the output HTML. The work was done, the code was correct, and the result was discarded one step before it mattered. Nobody reviews the metadata of a site they wrote the metadata for — you remember writing it, so you assume it's there.

How to check yours. Open four pages in four tabs and read the tab labels: four different titles is correct, four identical ones means your per-page metadata isn't being applied. From a terminal:

In Search Console, the Pages report under Indexing often names this directly as "Duplicate without user-selected canonical" or "Alternate page with proper canonical tag" — Google saying it has decided your pages are the same page.

Cause 4: Structured data was dropped by the same bug

What it looked like. Our JSON-LD — the structured data that tells Google what kind of business this is, where it operates, what it sells — was written and correct. It lives in <script type="application/ld+json"> tags. The metadata injector ignored script tags entirely, so none of it reached the live pages.

Why this is easy to miss. The Code tab of Google's Rich Results Test validates code, not pages. Pasted code always passes, because you're testing the snippet rather than the page it's supposed to be on. Testing the code and testing the page feel like the same action, and only one of them is.

How to check yours. Go to Google's Rich Results Test and use the URL tab, not the Code tab. Test the live, public URL. If it reports no structured data while your source clearly contains it, your build or your plugin is stripping it. Terminal version:

Zero on a page you know has schema is your answer.

Cause 5: Google Analytics was the literal placeholder `G-XXXXXXXXXX`

What it looked like. The measurement ID in our tracking code was G-XXXXXXXXXX — the placeholder from the documentation. Not a wrong property. Not a stale property. A property that has never existed. We had never measured a single session on our own website.

Why it silently persisted. Analytics reporting to nothing looks identical to analytics reporting to something you never open. There is no error state. The script loads, fires, and posts to an endpoint that discards it. And nobody was checking, because nobody expected the number to be interesting. A missing report doesn't ring a phone.

There's a second-order effect worth naming: because we had no analytics, we had no evidence that traffic was zero. The invisibility hid itself.

How to check yours.

Compare that against the Measurement ID in GA4 under Admin → Data Streams. If your GA4 loads through Tag Manager, the ID won't appear in the page source at all — check the container instead. Then do the live test: open your site in a private window and watch the GA4 Realtime report. If you don't appear within about a minute, something in the chain is broken — but rule out ad blockers, an unaccepted consent banner and internal-traffic filters before you blame the tag.

Cause 6: No Search Console property existed, and the verification tag said `YOUR_CODE_HERE`

What it looked like. There was no Google Search Console property for our domain. The verification meta tag in our HTML contained the literal string YOUR_CODE_HERE.

Why it silently persisted. Search Console is the one tool that would have told us about all five faults above, in plain language. On every client build, GA4 and Search Console go live on day one. We never did it for ourselves, and because we never did, no system anywhere was watching our indexing.

How to check yours. Log in to Search Console and see whether a property exists for your domain. If one does, open the Pages report under Indexing and read the "Why pages aren't indexed" table — it names the reason page by page. It's the first screen we open on any site that isn't indexing. If no property exists, create one — domain-level verification via DNS is the most durable — and submit your sitemap.

A placeholder there means your verification never completed.

Why this happened to an agency that does this for a living

All six faults existed on our site during months when the client work was going fine. On one client's Google Ads account we found and removed 721 Performance Max "conversions" that were not conversions at all, and rebuilt the tag manager container behind them. On another we found a quote-form conversion that had never fired once — every enquiry through that form had been invisible to the account for as long as it had existed. Finding those is the same skill as finding what was wrong with this site: read what the tools actually report, not what the dashboard summarises.

So the checks work. We run them. They just ran on everyone except us.

The reason isn't mystery and it isn't hypocrisy. Your own website is the only site in your portfolio that nobody is paying you to look at. Client sites have a ticket, a reporting cadence, a monthly call where someone asks a question you have to answer with a number. Your own site has none of that, and work that isn't scheduled and isn't owned doesn't fail loudly — it just quietly doesn't happen, for months.

Add to that the specific shape of these bugs: every one produced a success signal. The build passed. The deploy succeeded. The pages looked right in a browser. The analytics script loaded without error. We see the same pattern in client accounts — one beauty services client's ads recorded 583 click-conversions in 30 days against zero actual bookings. Confident, wrong reporting is worse than no reporting. If you only look at outputs that report their own status, you will conclude everything is fine indefinitely.

How to check yours in 10 minutes

Run these in order. Any one of them failing is worth acting on.

1. site:yourdomain.com.au in Google. Nothing back, or far fewer results than you have pages? Keep going.

2. View Source on your homepage. Not Inspect Element. Can you find your headline text in the raw HTML? If not, you're serving a shell.

3. Check your canonical. curl -s https://yourdomain.com.au | grep -i canonical, or search the source. It must show your live domain, on more than one page.

4. Compare titles across four URLs. Identical titles mean your per-page metadata isn't being applied.

5. Open yourdomain.com.au/robots.txt and search your source for noindex. A Disallow: / or a noindex left in from development is one of the most common reasons a site never gets indexed.

6. Rich Results Test — URL tab, not Code tab. Test the live page.

7. Match your GA4 ID against Admin → Data Streams, then confirm yourself in the Realtime report from a private window.

8. Open Search Console. No property? Create one now. One exists? Read Indexing → Pages → "Why pages aren't indexed".

Ten minutes gets you a yes or no on all eight, and tells you whether the problem is worth a developer's time.

What changed after we fixed it

The homepage went from 6,152 bytes with zero h1 elements to 64,322 bytes of real content. All 13 pages now ship unique titles. Canonicals point at the real domain.

Indexing is not instant, and as I said at the top, we haven't measured a recovery yet. What I can say is that for months the honest answer to "why isn't tivadigital.com.au on Google" was: because we told Google it lived somewhere else, and when Google looked anyway, we handed it a blank page.

If your site isn't showing up, the answer is very likely to be something equally unglamorous. Start with site:, then View Source, then Search Console. Fix what those three tell you before you spend a dollar on content or links, because neither will help a page Google has been instructed to ignore.

If you'd rather have someone run it for you, call 0404 997 841 or email support@tivadigital.com.au with your domain. We'll run the eight checks above, tell you which ones fail and what's causing each, and show you the raw HTML rather than a score out of 100. We're in Melbourne and we work with businesses across Australia.