Why Isn't My Business Showing Up on Google? Website Architecture, Indexing, Entity Signals, Technical SEO, and GEO

A website opening in your browser does not establish that Google sees the same thing. A page may be undiscovered, inaccessible to crawling, represented by another canonical URL, or simply not selected for a particular query. Before prescribing “SEO work,” identify the failing layer with evidence.

This article treats visibility as a systems problem connecting web architecture, HTTP behavior, indexing policy, business identity, and measurement. Engineering detail is paired with what a business owner can actually observe. Our example is a B2B service company rebuilding its website, publishing Turkish and English pages, and offering ERP integration.

Our companion guide, Why is my business not on ChatGPT?, covers answer-side visibility. Here we go deeper into the web and indexing infrastructure that supports discovery. See our AI Search Optimization (GEO) service for implementation scope.

1. Separate discovery, crawling, indexing, and ranking

Turn “we are not on Google” into a reproducible observation: which domain, exact URL, query, country/language, device, and date? Separate a brand-name search from an unbranded need such as “company developing ERP integrations.” Organic web results, Maps listings, and sources inside AI answers are different measurements.

In everyday terms, having an address online, being included in a catalogue, and being selected for a question are separate outcomes. Rather than stopping at one score or screenshot, state which link in that chain has actually been verified.

2. HTTP, DNS, TLS, and WAF: what does Googlebot receive?

Start with the response contract, not the browser screenshot. Does DNS reach the intended server, is TLS valid, do redirects reach the final page, and what does a GET request receive? Browser cache or session cookies can hide defects. Combine an unauthenticated request with server logs and Search Console URL Inspection.

# Inspect the actual GET response, including headers and body.
curl -sS -D headers.txt -o page.html   https://example.com/tr/services/erp-integration

# Review the redirect chain and final destination separately.
curl -sS -L -D redirect-chain.txt -o final.html   http://example.com/tr/services/erp-integration

# HEAD can be useful, but does not prove GET behaves identically.
curl -I https://example.com/tr/services/erp-integration

# Record status, Location, X-Robots-Tag, Content-Type, cache headers,
# canonical, title, visible text, and the time of the observation.

An existing public service page normally needs a final 200 response containing meaningful HTML. A moved URL needs an appropriate permanent redirect; a genuinely removed page needs 404/410. Returning “not found” with 200 can create a soft-404 problem, while redirecting every old URL to an unrelated homepage is not a sound migration. Status codes and business meaning should agree.

A CDN or WAF may replace content with 403, CAPTCHA, or even a challenge page returning 200. A status-only test would incorrectly pass the last case; verify expected content in the body too. Google crawlers can slow down after 429/5xx responses. Identify the offending rule instead of disabling protection wholesale. See Google’s HTTP handling guidance.

A User-Agent containing “Googlebot” is not authentication. Use the provider’s documented verification methods and published IP information when classifying traffic. Spoofing a User-Agent in curl only compares delivery behavior; it does not prove a real Google visit or index inclusion. See Google’s crawler overview.

3. robots.txt and noindex control different things

robots.txt governs access for compliant crawlers. noindex tells supporting search engines not to index a resource. Blocking a URL in robots.txt can prevent the crawler from seeing the noindex inside it. Nor is robots.txt a security boundary for a private administration panel; that needs authentication. See Google’s robots.txt introduction.

<!-- Accidental staging directive copied into production -->
<meta name="robots" content="noindex, nofollow">

# A header can exclude a resource even when HTML looks correct:
HTTP/2 200
Content-Type: text/html; charset=utf-8
X-Robots-Tag: noindex

# Public service pages: remove unintended noindex at its real source.
# Private customer areas: keep authentication and intended exclusion.
# Do not replace a deliberate privacy/access policy with blanket indexing.

The cause may live outside application code: staging configuration, a reverse proxy, a CDN response-header rule, or a CMS visibility setting. After the fix, invalidate the relevant cache and inspect another real GET. Removing a line from source does not establish that the CDN stopped serving its old header. See Google’s noindex implementation guidance.

For the business owner, this is like discovering an accidental “no visitors” notice on the sales office. More promotional copy will not remove it. Opening private customer accounts is not the answer either: public service information and private transaction areas need separate policies.

4. Website architecture: does the page exist before JavaScript runs?

A service page can look complete in your browser while its initial response contains only an empty application shell. Content then depends on an API that may fail because of cookies, CORS, rate limits, or rendering defects. Google can process JavaScript; that does not establish successful processing of every dependency under every condition. See Google’s JavaScript SEO guidance.

For public services and guides, we prefer SSR, static generation, or reliable prerendering so the main content arrives in the initial HTML. An interactive customer dashboard has different needs. Avoid technology labels such as “React bad, WordPress good”; inspect what each page type serves, with which response and update policy.

Compare three outputs: the origin response, the CDN response for an unauthenticated visitor, and the view processed in URL Inspection. Critical text, headings, canonical URLs, and links should agree. The objective is reliable delivery of the same information, not a different marketing page for crawlers.

<!doctype html>
<html lang="tr">
<head>
  <title>ERP Entegrasyonu ve Özel Yazılım | Örnek İşletme</title>
  <meta name="description" content="Gerçek hizmet kapsamı ve entegrasyon yaklaşımı.">
  <link rel="canonical" href="https://example.com/tr/services/erp-integration">
</head>
<body>
  <main>
    <h1>İşletmeler için ERP entegrasyonu</h1>
    <p>Hizmet kapsamı, veri sahipliği ve desteklenen süreçler burada açıklanır.</p>
    <a href="/tr/case-studies/order-integration">İlgili uygulamayı inceleyin</a>
  </main>
</body>
</html>

This is a readable delivery contract, not a ranking recipe. Choosing a CMS does not automatically satisfy it. Custom development still needs migrations, cache invalidation, meaningful error pages, and recovery behavior.

5. Canonical, redirects, and hreflang: which URL represents the page?

One service can appear with and without a trailing slash, tracking parameters, or another hostname. Define a URL policy rather than treating every variant as another SEO target: preferred versions, moved addresses, tracking parameters, and meaningful filters. Internal links, sitemap entries, redirects, and canonical tags should support that policy. A canonical is a strong signal, not an instruction Google must invariably follow. See canonical methods.

Common defects include a shared layout emitting the homepage canonical on every service, or English pages canonicalizing to Turkish. Genuine translations should identify the appropriate URL for each language; reciprocal hreflang annotations connect those alternatives. Adding hreflang does not repair a contradictory canonical.

<!-- On the Turkish page -->
<link rel="canonical"
      href="https://example.com/tr/services/erp-integration">
<link rel="alternate" hreflang="tr"
      href="https://example.com/tr/services/erp-integration">
<link rel="alternate" hreflang="en"
      href="https://example.com/en/services/erp-integration">
<link rel="alternate" hreflang="x-default"
      href="https://example.com/tr/services/erp-integration">

<!-- On the English page: same alternate set, English canonical. -->
<!-- x-default is an intentional fallback choice, not a ranking boost. -->

A language switcher should reach the equivalent page, not always the homepage. Mandatory location/IP redirects can also make language versions difficult to access. Check that alternate URLs return 200, identify appropriate canonicals, and connect reciprocally. See Google’s localized-version guidance.

6. Sitemaps and internal links: publishing is not discovery

A sitemap is a search-facing view of the publication inventory. Keep staging hosts, redirects, and deliberately non-indexable pages out of that intended inventory. Do not reset every lastmod to “today” on every deployment; reflect meaningful content updates. Successful sitemap submission does not establish index inclusion for every listed URL.

Do not leave page relationships solely inside a sitemap. Connect the main service, relevant guide, and actual case study. Link text should explain the destination rather than multiply keywords through unrelated footer links. A page visible only in administration—or accessible only to someone who already knows its URL—may be orphaned in the publication architecture.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/tr/services/erp-integration</loc>
    <lastmod>2026-11-01</lastmod>
  </url>
  <url>
    <loc>https://example.com/en/services/erp-integration</loc>
    <lastmod>2026-11-01</lastmod>
  </url>
</urlset>

Filters and sorting combinations can create an effectively unbounded URL space in large catalogues. That calls for crawl-space control. It does not mean every indexing issue on a small business site is a crawl-budget problem. Prioritize accessible, distinct, well-connected pages that genuinely serve a need. See Google’s sitemap guide.

7. Read Search Console as evidence, not as a diagnosis

A domain property and a URL-prefix property may cover different scopes. Inspect the correct protocol, hostname, and exact URL before declaring the site indexed. Separate URL Inspection’s indexed view from its live test: one concerns recorded state, the other current retrieval and processing. A successful live test does not guarantee indexing or ranking. See URL Inspection documentation.

This table does not assign one automatic cause. “Crawled — currently not indexed” alone proves neither a spam penalty nor an inadequate server or framework. Sample representative URLs and test hypotheses about templates, content, canonicals, and crawl timing. Exclusion can be correct for private areas and genuine duplicates. See the Page indexing report.

A site:example.com query is a quick observation, not a complete index inventory. Use URL Inspection for exact managed URLs, Page indexing for patterns, and search-performance reporting for queries. Check manual actions and security reports too rather than assuming one indexing label excludes every other issue. See the scope of the site: operator.

8. Entity signals: connect the page, service, and business

An entity is an identifiable thing: here, a business, branch, person, or service. A discoverable domain does not automatically explain what the business provides or where it operates. Names, contact details, actual service areas, service pages, and verified owned profiles should agree. Make those relationships explicit instead of repeating the brand in every sentence.

A shared data model can generate a stable organization @id, a service’s provider, and a page’s about/isPartOf relationships. Two language versions describing one business should not invent two organizations. sameAs identifies genuine profiles of the same entity, not competitors, arbitrary articles, or strong domains used as supposed authority transfers. See Google’s Organization guidance.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Business",
      "url": "https://example.com/"
    },
    {
      "@type": "Service",
      "@id": "https://example.com/#erp-integration-service",
      "name": "ERP integration",
      "provider": {"@id": "https://example.com/#organization"}
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/tr/services/erp-integration#webpage",
      "url": "https://example.com/tr/services/erp-integration",
      "inLanguage": "tr",
      "about": {"@id": "https://example.com/#erp-integration-service"}
    }
  ]
}

Markup is not a knowledge-graph registration form. Schema.org Validator checks structure, not independent factual truth. Rich Results Test focuses on Google-supported result features; not every valid schema type should appear there. Mark up what the page actually says rather than adding invisible awards, fabricated reviews, or unavailable services.

For the owner, conflicting telephone numbers or branch addresses are data problems to resolve first. For eligible businesses, accurate Business Profile information, categories, and location/service area can support local visibility. Maps also depends on relevance, distance, and prominence; entity work does not erase distance or purchase a position. See Google’s local-result guidance.

9. Index inclusion is not enough: answer the actual customer question

Suppose the example company’s homepage says only “innovative digital solutions.” That is insufficient for “I need a dealer ordering portal connected to my existing ERP.” Explain data ownership, supported workflow, required access, failure handling, project boundaries, and acceptance evidence. The title and H1 should describe that page’s actual subject.

Pair engineering terms with operational meaning: idempotency prevents one logical order from creating another when repeated; migration rollback describes a safe recovery plan when a release fails. This makes technical substance inspectable to the buyer rather than removing the substance.

Hundreds of pages differing only by a city name do not answer these needs. Without actual service coverage or meaningful local differences, extra URLs do not add information. A service → guide → actual case study relationship is more maintainable. If several pages target the same need, differentiate their scope or plan an appropriate consolidation.

10. Operate technical SEO through performance, logs, and release controls

Performance is more than a PageSpeed score. DNS/TLS, TTFB, main-content delivery, images, interaction delay, and layout shifts need distinct investigation. Lab tests help debug; field data, when sufficient, describes real-user experience. Record device, URL, date, and data source before drawing site-wide conclusions from one number. See the Core Web Vitals report.

Observe verified crawler requests, response codes, latency, canonical destinations, and unexpected responses. A 200 log entry does not establish correct content; a synthetic check can verify an expected H1 or page identity too. Do not log customer secrets, tokens, or personal data for an SEO report. Review query parameters and retention as well.

{
  "url": "https://example.com/tr/services/erp-integration",
  "environment": "production",
  "release": "release-reference",
  "request_method": "GET",
  "http_status": 200,
  "body_kind": "expected_service_html",
  "x_robots_tag": null,
  "meta_robots": "index, follow",
  "declared_canonical": "https://example.com/tr/services/erp-integration",
  "google_selected_canonical": "record-from-url-inspection",
  "inspection_time": "record-actual-timestamp",
  "crawler_identity": "verified-separately"
}

Example release gates: no unintended noindex on public services, appropriate redirects for critical moved URLs, matching canonical/hreflang relationships in both languages, no broken internal links, and intended sitemap entries. These are software acceptance controls, not a scorecard of Google’s algorithm.

Content, metadata, JSON-LD, and caches need coordinated updates. New body text with an old cached canonical is a partial release. Retain the build version, change list, controlled rollout, and recovery point alongside source files. Technical SEO belongs in the publication lifecycle, not a one-time plugin installation.

11. The GEO connection: indexing, AI citation, and recommendation differ

Google’s AI Overviews and AI Mode retain foundational SEO requirements; there is no mandatory “GEO schema” or special AI text file. Supporting-link eligibility requires indexing and eligibility for a search snippet. Eligibility does not establish selection for a particular answer. See Google’s AI-feature guidance.

The shared engineering foundation is accessible sources, explicit business identity, consistent facts, and useful answers. Other AI platforms can use different sources and product behavior. Therefore, do not combine Google index counts, ChatGPT mentions, and quote requests into one “visibility score.”

For AI evaluation, separate branded and unbranded questions and record language, region, platform, displayed model, and search mode. Code a brand mention, an explicit recommendation, and an owned-domain citation as different observations. Our ChatGPT visibility guide explains the protocol and tools.

Our TankDev SEO and GEO case study documents implementation evidence on our own website. It distinguishes PageSpeed, sitemap, schema, and citation observations rather than treating technical validation as interchangeable with customer acquisition.

12. An implementation plan from diagnosis to verified release

Complete the illustrative incident: after the rebuild, the ERP service page opens but is absent from search. An unauthenticated GET returns 200 with a staging-derived X-Robots-Tag: noindex; the English page also canonicalizes to the homepage. The evidence now points to two publication defects, not a generic shortage of keywords.

Fix the proxy rule producing the header and invalidate its cache. Then test per-page canonical generation and language relationships. After checking another GET and processed content, inspect critical URLs in an authorized Search Console account, request recrawling where appropriate, and start dated tracking. Repeated submissions are not an acceleration strategy. See Google’s recrawling guidance.

An illustrative tracking plan records critical URLs and a baseline, logs fixes and deployment, and compares the same URL/query cohorts in subsequent observation windows. Consider seasonality, query mix, device, and content changes when interpreting clicks. A before/after chart alone does not prove the change caused all growth. Deployment and Google’s subsequent processing can occur on different dates.

The engineering scope covers diagnosis, URL/data models, required custom web development, access policies, validation, and operational ownership. Copywriting, translation, photography, and digital PR are not automatically included in infrastructure work. Specify who supplies business facts and content, who owns code/data, and where maintenance responsibility ends.

Visibility starts with knowing which system produces each fact. We design discovery, reliable delivery, identity relationships, and inspectable operations—not just another collection of tags.

To assess your current website in this framework, explore our AI Search Optimization (GEO) service. For measuring answer-side visibility, continue with our business visibility in ChatGPT guide.