MNQ-Catering-y-Evento/docs/seo-audit/mnqcatering.com-audit/findings/geo.md

GEO / AI Search Readiness Audit — mnqeventos.es (corrected)

Audit date: 2026-09-15 Live target audited: https://www.mnqeventos.es Method: Live DNS resolution, direct HTTP fetch (curl), SSR-aware rendering via render_page.py --mode auto, repository source inspection for the pending (undeployed) fix.

Correction notice: An earlier pass of this audit targeted mnqcatering.com, which is not a registered domain (WHOIS: no match; DNS: NXDOMAIN) — that was a mistake in the audit target, not a finding about the real site, and produced a meaningless 0/100 score. The real production domain is https://www.mnqeventos.es, confirmed live and resolving (169.58.117.246, HTTP/2 200 on /, /robots.txt, /llms.txt). This document replaces that earlier pass entirely.

Summary

The live site is technically reachable and reasonably crawlable (SSR HTML, permissive robots.txt, working llms.txt), but it is actively telling every crawler — including every AI crawler in scope — the wrong canonical domain. The canonical tag, Open Graph tags, JSON-LD entity url, the robots.txt Sitemap: directive, and the visible footer link all point to mnqcatering.com, a domain that is unregistered and does not resolve. This is a live, current-production defect (not a legacy leftover in docs) with direct GEO consequences: AI crawlers that respect canonicalization will attribute this content to a dead URL, entity graphs built from the CateringService JSON-LD will resolve to a broken url field, and og:image/og:url previews (used by some AI answer engines for citation cards) will fail to load.

The good news: the root cause is already fixed in the repository (commit a6692b7 fix(seo): correct canonical domain to www.mnqeventos.es, plus astro.config.mjs, MainLayout.astro, SiteFooter.astro, contacto.astro, public/robots.txt, public/llms.txt all now reference mnqeventos.es) — it just has not been deployed to production yet. The live llms.txt served today is also a stale, thinner version missing the address and area-served lines that exist in the repo's current llms.txt. Once deployed, several of the findings below resolve automatically; I've flagged which ones.

Findings

1. Canonical URL, Open Graph, and JSON-LD entity url all point to a dead domain — HIGH (live defect, fix pending deploy)

• Severity: High
• Evidence (live, fetched 2026-09-15):
  • <link rel="canonical" href="https://www.mnqcatering.com/"> on /, and https://www.mnqcatering.com/contacto, https://www.mnqcatering.com/nosotros on those pages respectively.
  • <meta property="og:url" content="https://www.mnqcatering.com/">, <meta property="og:image" content="https://www.mnqcatering.com/images/foto-bodas.jpg"> — the image URL will fail to load for any consumer (AI citation card, social preview) since mnqcatering.com does not resolve.
  • JSON-LD CateringService schema on /, /contacto, /nosotros: "url":"https://www.mnqcatering.com".
  • Footer visible link: <a href="https://www.mnqcatering.com">www.mnqcatering.com</a> on every page — a dead outbound link on a live site.
  • umami analytics script tag: data-domains="www.mnqcatering.com" (low GEO impact, but confirms the whole template still ships the old domain).
• Impact: AI/search crawlers that respect rel=canonical will index/attribute content to a non-existent URL, which can suppress citation entirely or cause AI engines to silently drop the page from consideration when the canonical target 404s/fails to resolve. Structured-data entity resolution (how Google/Bing/AI systems build a knowledge-graph node for "MNQ Catering y Evento") is anchored to a broken url field.
• Status: Already fixed in repo (astro.config.mjs: site: 'https://www.mnqeventos.es', MainLayout.astro line 33/98, SiteFooter.astro line 22, contacto.astro line 108) but not yet deployed.
• Recommendation: Deploy the pending fix immediately. This is the single highest-impact, already-solved change — it just needs to ship. Effort: none (code complete), deploy only.

2. robots.txt Sitemap directive points to a domain that does not exist — HIGH (live defect, fix pending deploy)

• Severity: High
• Evidence (live):

  User-agent: *
  Allow: /
  
  Sitemap: https://www.mnqcatering.com/sitemap-index.xml
  

  Verified: curl -o /dev/null -w '%{http_code}' https://www.mnqcatering.com/sitemap-index.xml → connection failure / 000 (domain unregistered). The correct, working sitemap is live and reachable at https://www.mnqeventos.es/sitemap-index.xml → HTTP 200, but nothing in the live robots.txt points there.
• Impact: Crawlers that discover the sitemap only via robots.txt (a common pattern for AI/search crawlers doing full-site discovery) get a dead pointer and may fail to enumerate all indexable pages, slowing or preventing discovery of /bodas-reales, /corporativo-business, /reuniones-familiares, etc.
• Status: Already fixed in repo public/robots.txt (now points to https://www.mnqeventos.es/sitemap-index.xml) — pending deploy.
• Recommendation: Ships with fix #1's deploy. Effort: none, deploy only.

3. robots.txt is permissive for AI crawlers — GOOD (no action needed)

• Severity: Positive finding
• Evidence: User-agent: * / Allow: / — a single wildcard rule with no disallows. This implicitly allows GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, CCBot, anthropic-ai, and cohere-ai; nothing is blocked.
• Recommendation: No change needed. Optionally add explicit named-agent blocks for CCBot/anthropic-ai/cohere-ai only if the business wants to opt out of training-only crawling while keeping AI search visibility (GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot) — this is optional per the audit brief, not a defect.

4. llms.txt is present and live, but the deployed version is thinner and has the wrong canonical domain than the repo's current version — MEDIUM (live defect, fix pending deploy)

• Severity: Medium
• Evidence — live, fetched 2026-09-15 (https://www.mnqeventos.es/llms.txt, HTTP 200):

  MNQ Catering y Evento
  
  - Canonical domain: https://www.mnqcatering.com
  - Business type: Premium catering service
  - Services: Bodas, eventos corporativos, reuniones familiares
  - Primary contact channels: WhatsApp (+34 678 17 15 13), phone (+34 678 17 15 13)
  - Key pages: /, /nosotros, /bodas-reales, /corporativo-business, /reuniones-familiares, /contacto
  

  • Repo's current public/llms.txt (committed, not yet deployed) adds two lines the live version is missing:

  - Address: Calle Camino Vivero, 6, 29014, Málaga, España
  - Area served: Málaga (city) and Provincia de Málaga
  

  and correctly says Canonical domain: https://www.mnqeventos.es.
• Format note (applies to both live and repo versions): Neither follows the llms.txt spec convention closely — no # Title H1, no > summary blockquote, no markdown-style [Key Page](full-url): description links (currently plain relative paths in a flat bullet list). This is a minor quality gap versus the informal but now-common llms.txt convention; it doesn't block parsing but is a missed opportunity for AI agents that expect the structured format.
• Recommendation: Deploy the repo's current version immediately (fixes domain + adds address/area-served — real local-entity signals). Separately, reformat to standard llms.txt structure (H1 title, one-line summary blockquote, markdown links per key page with a short description each) for better parseability by LLM-based agents. Effort: Low (content already exists, just needs reformatting).

5. No FAQ-style content on the homepage; direct-answer content is confined to /contacto — MEDIUM

• Severity: Medium
• Evidence: /contacto carries a genuine FAQPage JSON-LD block with 3 Q&A pairs (e.g. "¿Qué datos conviene enviar para pedir una propuesta?" → "Fecha estimada, lugar del evento, número aproximado de asistentes y el tipo de servicio que necesita.") and matching visible question-format subheadings ("Qué necesitamos para orientarle", "Cómo planteamos el presupuesto"). This is a genuine AEO positive — but it exists only on one page. The homepage, /nosotros, and the three service pages (not fetched this pass, but referenced identically in nav) use marketing prose headings ("Servicio planificado según ubicación, formato y ritmo del evento") rather than question-based H2/H3s, and no passage on the homepage is a self-contained 134–167-word answer block — most are 1–3 short sentences of brand copy.
• Recommendation: Extend the FAQPage + question-based-heading pattern already proven on /contacto to the service pages (bodas, corporativo, reuniones-familiares) and /nosotros, each with 3–5 self-contained Q&A pairs in the 40–80 word range (FAQ answers don't need to hit the full 134–167-word "article passage" target, but should stay self-contained and specific). Effort: Medium — content writing + schema markup, reusing the existing /contacto pattern as a template.

6. No brand/entity linking signals (no sameAs, no social profile links anywhere on-site) — MEDIUM-HIGH

• Severity: Medium-High
• Evidence: Checked /, /contacto, /nosotros for LinkedIn, Instagram, Facebook, X/Twitter, YouTube, TikTok links — zero matches. The CateringService JSON-LD has no sameAs array. No mentions of Wikipedia, Reddit, or YouTube presence found on-site (external presence not independently verified this pass — no search/social-listening tool was used).
• Impact: Per the brand-mention correlation data, YouTube mentions (~0.737) and Reddit presence are the strongest predictors of AI citation; Wikipedia entity presence is also high-value. Zero on-site sameAs/social signals means AI systems building an entity profile for "MNQ Catering y Evento" have nothing to cross-reference beyond the domain itself.
• Recommendation: (a) Add a sameAs array to the CateringService JSON-LD linking to whatever active social profiles exist (Instagram/Facebook are typical for catering businesses even without LinkedIn/YouTube). (b) If no social profiles exist yet, creating even a modest Instagram/YouTube presence (venue photos, event highlight reels) would meaningfully move the needle given YouTube's outsized correlation with AI citation. Effort: Low for sameAs markup (if profiles exist), Medium-High for building new social presence from scratch.

7. No address / local-entity structured data live (fix pending deploy) — MEDIUM

• Severity: Medium
• Evidence: Live JSON-LD CateringService on /, /contacto, /nosotros has no address, areaServed, or geo fields — only name, url (wrong domain), description, telephone, serviceType, contactPoint. No address text appears anywhere in the visible page copy either. The repo's current llms.txt (undeployed) already has the address/area-served text; it's unclear from this pass whether the CateringService JSON-LD itself is being updated with structured address/areaServed/geo fields, or whether the fix is llms.txt-only.
• Recommendation: Once the domain fix deploys, separately confirm (or add) structured address and areaServed fields inside the CateringService JSON-LD itself (not just llms.txt prose) — this is what powers Google's local entity panel and is a stronger machine-readable signal than plain text. Effort: Low, since the address text is already sourced (Calle Camino Vivero, 6, 29014, Málaga, España).

8. Server-side rendering confirmed — GOOD (no action needed)

• Severity: Positive finding
• Evidence: render_page.py --mode auto on https://www.mnqeventos.es/ returned "is_spa": false, "mode_used": "raw" — the raw HTTP response already contains the full rendered page (hero copy, service cards, testimonials, footer, all JSON-LD) with no client-side hydration gap. This matches the Astro output: 'server' architecture confirmed in astro.config.mjs.
• Recommendation: No change needed. This is the single strongest technical-accessibility asset the site has — every AI crawler sees the same content a browser does, with zero JS-execution risk.

9. Descriptive image alt text present — GOOD (partial credit)

• Severity: Positive finding, with a gap
• Evidence: Homepage images carry specific, descriptive alt text (e.g. "MNQ Catering — salón de bodas premium", "Vieiras con azafrán", "Bartender de coctelería") rather than generic/empty alts. However, there is no video content anywhere observed, and no image captions or surrounding text that would let an AI engine extract a citable fact from an image (e.g. no recipe steps, no menu item descriptions tied to photos).
• Recommendation: Keep the alt-text discipline for new images. Consider short video content (event highlight reels) for the Multi-Modal dimension, given video/YouTube's strong correlation with AI citation.

GEO Health Score

Overall: 46 / 100

Dimension	Weight	Score (0–100)	Weighted	Rationale
Citability	25%	50	12.5	Solid FAQ schema + Q&A headings on /contacto; homepage/other pages are marketing prose, not self-contained answer blocks
Structural Readability	20%	55	11.0	Clean heading hierarchy; question-format H2/H3 only on /contacto, not site-wide
Multi-Modal Content	15%	35	5.25	Good descriptive alt text; no video, no YouTube presence, no image-adjacent citable facts
Authority & Brand Signals	20%	30	6.0	No sameAs/social links, no visible address/local-entity data live, wrong canonical/entity url currently live
Technical Accessibility	20%	55	11.0	SSR confirmed, permissive robots.txt, fast HTTP/2 — undercut by broken canonical, broken sitemap pointer, broken og:image

If the already-committed domain fix (commits a6692b7 and related) is deployed as-is, Technical Accessibility and Authority & Brand Signals would both improve materially (est. +15–20 points combined toward Technical, +5–10 toward Authority once address data ships in structured form), pushing the overall score into the high-50s/low-60s without any new work — that deploy is by far the highest-leverage action available right now.

AI Crawler Access Status (robots.txt, live)

Crawler	Status
GPTBot	Allowed (wildcard Allow: /)
OAI-SearchBot	Allowed (wildcard Allow: /)
ClaudeBot	Allowed (wildcard Allow: /)
PerplexityBot	Allowed (wildcard Allow: /)
CCBot	Allowed (wildcard Allow: /) — no opt-out currently configured
anthropic-ai	Allowed (wildcard Allow: /) — no opt-out currently configured
cohere-ai	Allowed (wildcard Allow: /) — no opt-out currently configured

Note: robots.txt itself is reachable, but its Sitemap: directive is broken (see Finding #2), which can hinder full-site discovery regardless of the permissive Allow rule.

llms.txt Status

Present, HTTP 200, but stale/incomplete relative to the repo's current (undeployed) version.

• Live: 5 bullet lines, wrong canonical domain (mnqcatering.com), no address/area-served.
• Repo (pending deploy): 7 bullet lines, correct canonical domain, includes address and area served.
• Neither version follows the full llms.txt markdown convention (H1 + summary + linked key pages) — see Finding #4.

Brand Mention Analysis

Not independently verified via external search/social-listening tools this pass (none available in this environment/session). On-site evidence only: zero sameAs links, zero social profile links (Instagram/Facebook/LinkedIn/YouTube/TikTok/X) found in the HTML of /, /contacto, /nosotros. This is a gap regardless of what external presence may exist, since AI entity-resolution systems weight on-site declared links (sameAs) heavily as a disambiguation signal. Recommend a follow-up pass with live search/social tools (or DataForSEO's ai_opt_llm_ment_search, if that MCP integration is enabled for this environment — it was not available this session) to check actual Wikipedia/Reddit/YouTube/LinkedIn mention volume before investing in new social presence.

Platform-Specific Scores (qualitative estimate — no live scraping tool available this session)

Platform	Estimated readiness	Basis
Google AI Overviews	Low-Medium	FAQPage schema present (favorable), but broken canonical/entity URL currently live undercuts trust signals
ChatGPT (browsing/search)	Low	No llms.txt linking convention, weak brand-mention surface, broken og:image would fail citation-card rendering
Perplexity	Low-Medium	Permissive robots.txt and clean SSR content favor crawlability; same entity/URL trust gap as above
Bing Copilot	Low-Medium	Same reasoning as Google AIO (shares underlying Bing index signals)

These are directional estimates based on on-site signals only, not live AI-response testing. If DataForSEO's ai_optimization_chat_gpt_scraper becomes available in a future session, re-run for actual observed visibility rather than inferred readiness.

Top 5 Highest-Impact Changes

1. Deploy the already-committed domain fix to production — Effort: None (code complete) / Impact: High. Fixes canonical tags, og:url/og:image, JSON-LD url, footer link, and the broken robots.txt sitemap pointer in one deploy. This is the single highest-leverage action and requires zero new development.
2. Confirm the deployed llms.txt matches the repo's current version (with address + area-served) after deploy, and reformat it to standard llms.txt markdown convention (H1, summary blockquote, linked key pages with descriptions) — Effort: Low.
3. Add structured address/areaServed/geo fields to the CateringService JSON-LD (not just llms.txt prose) on /, /contacto, /nosotros — Effort: Low, address text already sourced.
4. Extend the /contacto FAQPage + question-heading pattern to the three service pages and /nosotros — Effort: Medium, reuses an existing, working template.
5. Add a sameAs array to the JSON-LD entity linking real social profiles (or build a minimal video/YouTube presence if none exist) — Effort: Low if profiles exist, Medium-High if starting from zero; highest-correlation lever per the brand-mention data once other fixes ship.

What Already Works Well

• Genuine SSR, no hydration gap. render_page.py confirms the raw HTTP response is the full page — every AI crawler sees complete content with zero JS-execution dependency.
• Permissive robots.txt. No AI crawler (GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot) is blocked; a single wildcard Allow: / covers everything.
• llms.txt exists and is live (HTTP 200), and the repo's pending version is well-formed content-wise (business type, services, contact channels, key pages, address, area served) even if the markdown formatting could be tightened.
• Real FAQPage schema + question-based subheadings on /contacto, with concise, accurate, self-contained answers — this is exactly the AEO pattern that should be replicated site-wide.
• Descriptive, specific image alt text throughout the homepage gallery and service cards.
• Fast, modern hosting: HTTP/2, alt-svc: h3, clean response headers, no redirect chains observed on the pages checked.
• The hard part (root-cause domain fix) is already done in code — the team caught and fixed the canonical-domain issue proactively; it's purely a deployment gap away from resolving several of the findings above.