Spectavi Compliance SEO AI Visibility Google Maps UX

Case study · AI phone-assistant SaaS, DACH market

Full visibility audit — five angles, one page

Our client builds an AI phone assistant for the German-speaking market — a fast-growing SaaS with several thousand customers and a strong independent-review track record. We checked five angles most SaaS teams never audit together: legal compliance, SEO, AI-search visibility (GEO), Google Business Profile, and UX/conversion. This is that same report format, shown here as a worked example — identifying details removed.

5 audits ~30 pages sampled 3 competitors checked 3 live AI-search tests

Anonymized example: company name, domain, address, phone numbers, founder names and competitor/customer names have been removed or replaced. Every finding, number and mechanism below is real and unmodified.

Main takeaway

The client's foundation was genuinely strong — real independent reviews, a standout low-friction demo CTA, and enough SEO structure to already get cited by name in AI-generated answers for niche queries. The gaps were specific and fixable, not existential: the cookie-consent banner pre-enabled tracking by default (a real GDPR consent problem, not a cosmetic one), the Impressum was missing a legally required registration number, no page carried Organization/LocalBusiness structured data so AI systems had no machine-readable answer to "who is this company," and the business had two separate, inconsistent Google Business Profiles — a strong one the homepage itself promoted, and a near-empty duplicate with a different phone number. None of it needed a rebuild — most of it was configuration and template-level work.

01 · Snapshot

The numbers behind the verdict

Real counts from this audit, not composite scores — each one traced to a specific check further down the page.

2
Impressum & privacy-policy gaps with real legal weight
~1/4
sampled pages missing a meta description
~40%
of sampled pages with empty social-share description tags
0
pages with Organization/LocalBusiness schema
2
separate, inconsistent Google Business Profiles
4/4
cookie categories pre-enabled by default
Needs fixing

03 · Compliance

Impressum & Datenschutz (Austria)

A GmbH registered in Vienna. Checked against §5 ECG, §25 MedienG and DSGVO/GDPR requirements.

Impressum is missing the Firmenbuch number

The Impressum correctly listed the address, VAT ID, email and phone, and named the managing directors. As a registered GmbH, its Impressum is expected to also state the Firmenbuchnummer and Firmenbuchgericht — neither appeared. The number itself was already public via the Austrian company register, so this was a copy-paste fix, not a filing.

Also missing: GISA number, the supervisory/trade authority, chamber membership (WKO), and the minimal §25 MedienG "Offenlegung" statement (name, place, business purpose) — all low-effort, standard additions for an Austrian GmbH.

Fix: add Firmenbuchnummer + Firmenbuchgericht, GISA, authority and a one-paragraph Offenlegung. ~30 minutes of copy, no legal drafting required for the factual fields.

Privacy policy is "thin" relative to what the site actually does

The privacy policy named DSGVO/GDPR but was missing several core sections: an explicitly named controller (Verantwortlicher), a data-subject-rights section, the legal basis per processing activity (Art. 6 DSGVO), how to file a complaint with the supervisory authority, cookie policy detail, and disclosure of the specific third-party tools in use. That last point mattered concretely here: the site ran a product-analytics tool and a LinkedIn pixel (both directly confirmed), plus indirect signs of TikTok tracking — exactly the kind of processing a DSGVO-compliant policy needs to name and justify.

Fix: extend the privacy policy to name the controller, legal bases, rights, complaints authority, and the specific analytics/ad tools in use. This should be drafted or reviewed by counsel, not auto-generated.

What was already right

Address, VAT ID and phone were present and consistent everywhere we checked them (Impressum, footer) — that NAP consistency is a real trust signal, worth protecting rather than touching while fixing the gaps above.

Solid base, fixable gaps

04 · SEO

Technical & content SEO

Dozens of pages crawled directly across two passes; the sitemap listed several hundred URLs (largely programmatic per-industry and per-case-study landing pages). Compared against three direct competitors in the same niche.

Missing meta descriptions and Open Graph tags — wider and more systemic than it first looked

A handful of sampled pages shipped with an empty meta description, including the changelog page and a couple of use-case landing pages. One product page had a real meta description but an empty OG pair.

Checking the social-share tags specifically (og:title, og:description, twitter:description) across every page sampled for this audit turned up a bigger pattern: roughly 4 in 10 pages had at least one empty field, and it was concentrated in one template — the large majority of case-study pages checked had an empty og:description and twitter:description, with only one exception. Since case studies are exactly the content most worth sharing — real named customers, real quotes — this read as a template-level bug in the case-study layout, not a handful of forgotten pages. The sitemap listed far more case studies than we sampled, so the true sitewide count was likely higher than what we checked directly.

Page typeMeta descriptionog:titleog:descriptiontwitter:description
ChangelogEmptyEmptyEmptyEmpty
Product/setup pageOKEmptyEmptyEmpty
Use-case landing pages (×2)EmptyOKEmptyEmpty
Case-study pages (most of those checked)OKOKEmptyEmpty

Search engines auto-generate an unpredictable snippet where the meta description is missing, and social shares show a blank description line wherever og:description is empty — confirmed directly by sharing one of the affected pages and watching the preview card render with a title but no description underneath.

One page also gave a clean before/after: a third-party link-preview tool's cached scrape from roughly a month before this audit still showed a real og:description for a product page — by the time we checked, it was empty. That points to a regression introduced by a deploy sometime in that window, not a field that was never filled in — worth checking against recent release history.

No explicit AI-crawler policy in robots.txt

The client's robots.txt was a blanket Allow: / plus a sitemap line — nothing wrong with it, but nothing deliberate either. Two direct competitors went further: one had a commented section in its robots.txt explaining exactly why AI crawlers were explicitly allowed (citations in ChatGPT, Perplexity, Claude, AI Overviews, Copilot), listing 15+ named bots; another used the newer Content-Signal directive for the same bots. Not a blocker — a positioning gap.

SignalClientCompetitor ACompetitor B
Explicit AI-crawler robots.txt policyNoYes, with rationale commentYes, Content-Signal
FAQPage schemaYesNoYes
Organization/WebSite schemaNoNoYes
Homepage weight~200 KB~250 KB~180 KB

Several images on industry pages were served larger than they were displayed

Industry-specific landing pages each carried a double-digit count of images flagged as larger than their displayed size — the browser downloads a bigger file than it actually shows on screen, which slows the page down for no visual benefit. This is a real risk for a metric called LCP (Largest Contentful Paint) — how long it takes the biggest visible element on the page to render — which affects both Google's ranking and whether a visitor waits around on a slow mobile connection.

Fix: serve each image at the size it's actually displayed (via srcset/sizes so the browser picks the right one), lazy-load anything below the fold, and preload the one large image that appears first on screen. The client already ran an image-resizing proxy — this was about passing it the right width per placement, not new infrastructure.

What was already right

FAQPage structured data was correctly implemented on most product and use-case pages — a genuine strength that also feeds directly into AI-answer extraction (see the AI Visibility section). Worth explicitly protecting the next time these templates are touched.

Mixed — real strengths, real gaps

05 · AI Visibility (GEO)

How ChatGPT, Claude, Perplexity and Google AI Overviews see the client

Dozens of pages scanned for AI-crawler access and structured data; three live search tests run to see what today's AI-style answers actually surface.

Live test: the client already got cited by name

A niche informational query in the client's category returned the client named directly, described in positive terms alongside two or three real competitors — a genuine, unprompted citation, not something we asked for.

Entity test (searching the brand name plus "reviews") — strong independent footprint across several B2B review platforms, consistently positive. One third-party summary in these results cited a lower customer count than the client states on its own site — a good example of exactly what this section is about: once a number about you is out in independent sources, you don't fully control which version an AI answer repeats. This was otherwise exactly the kind of third-party corroboration AI answer engines weight heavily.

Live test: absent from the commercial/pricing query

A commercial, price-oriented query in the same niche did not surface the client at all. Results were dominated by comparison/aggregator blog posts naming several specific competitors by product and price. The client competes directly on price and features here but wasn't one of the named examples.

Zero structured entity data, on every page checked

Across every page scanned, there was no Organization/LocalBusiness/Service/Product JSON-LD anywhere — only FAQPage schema. AI systems had no machine-readable answer to "what is this company, who runs it, where is it based, what does it cost," despite all of that sitting in plain text on the Impressum and pricing pages.

Fix: one Organization JSON-LD block (name, url, logo, address, founders, sameAs → review-platform profiles) added sitewide. A few hours of templating work, not new content.

Navigation loads before content on every single page

On every page sampled — homepage, use-case pages, and case-study pages — the extracted "first visible text" was the full mega-menu (Products / Solutions / Resources / Customer Stories / Pricing…) before any actual page content. AI answer engines weight the first ~30% of a page heavily when extracting what to cite; here that slice was 100% navigation on every page, including the case studies (named real customers with direct quotes) which carried the client's most citable, most specific proof content, had zero structured data of any kind, and — per the SEO section — were also the pages most likely to be missing their social-share description.

No llms.txt

/llms.txt and /llms-full.txt both 404. Not yet a wide standard, but a cheap, low-effort signal some AI crawlers already look for — worth bundling with the schema fix above rather than doing separately.

Duplicate listings — the strong one is real, the confusion is the problem

06 · Google Business Profile

Google Maps presence

The client is B2B SaaS — customers never visit the office, so Maps isn't a lead channel the way it is for a clinic or restaurant. Its value here is trust signal and NAP (name/address/phone) consistency, not foot traffic.

Two separate Google Business Profiles for the same company

The client had two live, distinct listings on Google, not one:

FieldProfile A (active)Profile B (duplicate)
CategoryTelecommunications contractorIT consultant
Rating / reviews4.5+★, several hundred reviewsNone
PhotosSeveral uploadedNone (default placeholder)
HoursOpen 24 hoursNot set
PhoneDoes not match the ImpressumMatches the Impressum exactly

The strong profile (Profile A) was the real, active one: it's what the review badge on the client's own homepage linked directly to, and it's what actually surfaced first in a plain commercial Maps search — so this wasn't a visibility problem in the sense of "nobody can find you." The problem was that a second, near-empty listing existed in parallel, under a different phone number than the one printed in the Impressum. Anyone who landed on the wrong one — via a slightly different search, an old citation, or a business directory — would see a company with no reviews and no hours, and there were now two different phone numbers attached to the same brand on Google, which is exactly the kind of NAP inconsistency that erodes trust signals for both Google and AI systems.

Fix: this is Google's standard duplicate-listing situation — claim/verify the thin profile if not already done, then request a merge via Google Business Profile support (or mark the duplicate as "permanently closed" if a merge isn't accepted), keeping the well-reviewed profile as the single source of truth. Update its phone number to match the Impressum while at it.

Minor polish on the strong profile

Once consolidated onto one listing: the category on the active profile was closer to reality than "IT consultant" was, but a more specific software-company category would fit an AI phone SaaS better still — worth considering. Everything else on this profile (reviews, photos, hours) was already in good shape.

Strong instincts, one real compliance risk

07 · UX & Conversion

First-screen experience and conversion path

Checked homepage and mobile rendering, HTTP→HTTPS behavior, security headers, analytics presence, and the consent flow.

Best-in-class primary CTA

A visitor could enter a phone number and immediately receive a live call from the AI assistant. No signup, no form, no pitch deck. Neither of the two competitors we checked offered anything like this; both defaulted to "book a demo" as the only path. This was a genuine differentiator and worth protecting, not diluting with extra steps.

Cookie consent banner pre-enabled tracking by default

On first load, the consent banner showed Necessary, Preferences, Statistics AND Marketing all toggled ON before the visitor clicked anything. Under GDPR/ePrivacy — and the CJEU's Planet49 ruling specifically on pre-ticked boxes — consent for non-essential cookies must be opt-in: off by default, actively switched on by the user. This was the same underlying gap flagged in the compliance section (no clear consent-mechanism description in the privacy policy) — the mechanism and the policy needed fixing together.

Fix: default Preferences/Statistics/Marketing to OFF in the consent-management tool's config. A settings change, not a rebuild.

No HSTS or Content-Security-Policy headers

HTTPS was correctly enforced (a clean redirect via the client's CDN), but the response carried no Strict-Transport-Security and no Content-Security-Policy header. Impact on most visitors is low since the redirect already lands them on HTTPS — a hardening item, not a conversion blocker, and typically a one-checkbox change given a CDN was already in front of the site.

What was already right

Specific, credible social proof on the very first screen (customer count, a strong independent rating, recognizable enterprise logos rather than generic ones); a clean mobile layout with no broken elements; a correct HTTPS redirect; and genuine analytics in place — a product-analytics tool and a LinkedIn pixel were both directly confirmed in the page source, plus indirect signs of a TikTok tracking cookie, likely routed through a server-side proxy. Worth noting explicitly since "no analytics" is often assumed without checking — that assumption would have been wrong here.

Want the same kind of report for your own site?

This is the real format we deliver — five audits, cross-checked findings, an independent fact-check pass before anything ships, and a prioritized fix list at the end. Leave your site and email below and we'll send a free demo audit.