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

Local SEO Audit — MNQ Catering y Evento

Audit date: 2026-09-15 Business: MNQ Catering y Evento — premium catering, Local Service business type Address (owner-confirmed): Calle Camino Vivero 6, 29014 Málaga, España Phone (owner-confirmed): +34 678 17 15 13

IMPORTANT — domain correction mid-audit

The audit was launched against https://www.mnqcatering.com, which does not resolve (confirmed NXDOMAIN via local resolver, and independently via the WebFetch tool's own DNS lookup — two different network paths both failed). The coordinator subsequently confirmed via WHOIS that mnqcatering.com was never registered, and that the actual canonical/live domain is https://www.mnqeventos.es.

All findings below marked LIVE were verified by directly fetching https://www.mnqeventos.es (home, /contacto, /privacidad, /cookies) just now. Findings marked REPO come from reading the Astro source in this working copy (/home/manuel/Documentos/Proyectos/MNQ Catering y Evento), which per the coordinator is mid-fix this session but not yet deployed.

Do not conflate the two. The repo checkout I read still has CANONICAL_HOST = 'www.mnqcatering.com' in src/middleware.ts and @type: 'CateringService' in src/layouts/MainLayout.astro (verified via git diff — no uncommitted changes to these files in this checkout), so whatever fix the coordinator describes (domain corrected, schema @type → CateringBusiness) exists in a different session/worktree, not in the files I inspected. I did not verify that fixed state directly — report it as coordinator-asserted, unconfirmed by me.

---

Summary

The live site (www.mnqeventos.es) has a severe, site-wide NAP and canonicalization problem that is worse than what the local repo checkout shows: every page checked has zero occurrences of the street address, postal code, or "Málaga" anywhere in the HTML (visible or structured), and every canonical tag, og:url, and JSON-LD url property on every page self-declares the domain as www.mnqcatering.com — a domain that is not registered. The phone number is present and consistent. The business name has a real plural/singular inconsistency baked into the site-wide header/footer logo alt/aria-label text. The only structured data on the live site is a single CateringService block (not a valid schema.org type) with no address, no areaServed, no geo.

The local repo checkout is meaningfully further along (has address in footer/contacto, has PostalAddress + areaServed in schema) but still carries the invalid CateringService type and the same name inconsistency, and still points at mnqcatering.com in its middleware/config as of this checkout.

GBP is not yet created — that's an acknowledged, expected gap given where this project is in its lifecycle, not scored as a site defect per se, but it does mean there is currently zero external signal reinforcing the business entity, which makes getting the on-site canonical/NAP layer exactly right more urgent, not less.

---

Findings

CRITICAL

1. [LIVE] Canonical tag, og:url, and JSON-LD url all point to an unregistered domain (mnqcatering.com), not the live domain (mnqeventos.es) Evidence, fetched from www.mnqeventos.es just now:

• <link rel="canonical" href="https://www.mnqcatering.com/"> (present on /, /contacto, and presumably every page)
• <meta property="og:url" content="https://www.mnqcatering.com/">
• JSON-LD: "url":"https://www.mnqcatering.com"
• Footer/nav links: href="https://www.mnqcatering.com/" and href="https://www.mnqcatering.com" This means the site's self-declared canonical identity — the single most important machine-readable signal for Google to associate the site with a future GBP listing — points at a domain that does not exist. This will confuse indexing (Google may treat the declared canonical as authoritative and effectively deprioritize/ignore the real, resolvable mnqeventos.es URLs) and would actively sabotage GBP verification/association once a listing is created, since the GBP website field must match a URL the site itself claims as canonical. Recommendation: Fix CANONICAL_HOST (and every hardcoded mnqcatering.com reference — astro.config.mjs site:, MainLayout.astro fallback URL, JSON-LD url, footer/contacto links, robots.txt sitemap line, llms.txt) to www.mnqeventos.es and deploy. This is the single highest-priority fix on the entire site.

2. [LIVE] No address anywhere on the live site — visible or structured Fetched and grepped /, /contacto, /privacidad, /cookies: "Camino Vivero", "29014", and "Málaga" each return 0 matches across all four pages. The phone number is present (+34 678 17 15 13, 2–3 occurrences per page) but the address is completely absent, including from /contacto, which is where a user (and Google) would most expect to find it. The live JSON-LD has no address property and no areaServed at all — just name, url (wrong domain), description, telephone, serviceType, contactPoint. Recommendation: Deploy whatever fixes address rendering on the live site (the repo checkout I read does have the address in SiteFooter.astro and contacto.astro, and PostalAddress + areaServed in the schema — so this may already be solved in a newer, undeployed commit). Until deployed, Google has literally nothing to anchor a "Málaga" local entity to on the live site.

3. [REPO, and confirmed live] @type: "CateringService" is not a valid schema.org type Verified directly against schema.org's own vocabulary (fetched schema.org/CateringService → HTTP 404; fetched schema.org/FoodEstablishment subtype list and the full current JSON-LD vocabulary dump → no type or label containing "Catering" or "Caterer" exists anywhere in schema.org). This type is live on www.mnqeventos.es right now (confirmed in the fetched JSON-LD) and is also what's in the repo checkout I read. An unrecognized @type means Google's structured-data parser has no LocalBusiness subtype to key off of — no rich-result eligibility, weaker entity understanding, and no reinforcement for a future GBP category match (primary GBP category is the #1 local ranking factor per Whitespark 2026, and a wrong/missing category is the #1 negative factor). Note: the coordinator states this was corrected to CateringBusiness in a fix not yet deployed. I could not verify CateringBusiness either way — it is also not a standard schema.org type as far as I could confirm (schema.org has no dedicated caterer subtype at all). The safest documented options are plain LocalBusiness (generic, always valid) or FoodEstablishment if the business wants to lean on the food-service branch, with additionalType/serviceType used to convey "catering." Whoever owns that fix should double-check CateringBusiness against schema.org before deploying — if it doesn't validate in Google's Rich Results Test either, it's the same problem under a new name.

HIGH

4. [LIVE + REPO] Business name inconsistency: "MNQ Catering y Evento" vs "MNQ Catering y Eventos" Confirmed on both the live site and in the repo source. The site-wide header logo (SiteHeader.astro) and footer logo (SiteFooter.astro) both use the plural "MNQ Catering y Eventos" in alt text and aria-label — this appears on literally every page since header/footer are global. Everywhere else — page <title> tags, og:site_name, the JSON-LD name property, the footer copyright line, llms.txt — uses the singular "MNQ Catering y Evento". Live grep counts on the homepage: plural form 4 occurrences (all header/footer), singular form 12 occurrences (title, meta, schema, copyright). Business Name is the "N" in NAP; an exact-match name is what Google uses to tie a website to a GBP listing. Two names in active use sitewide is a real, avoidable inconsistency. Recommendation: Pick one (the schema/title form, "MNQ Catering y Evento", is the one that should become the GBP business name — it's already dominant) and fix the two alt/aria-label occurrences in SiteHeader.astro and SiteFooter.astro to match.

5. [LIVE] No areaServed or geo in live schema (repo has areaServed, still no geo) Live JSON-LD has neither. The repo checkout's MainLayout.astro does include areaServed (City: Málaga + AdministrativeArea: Provincia de Málaga), which is good and correctly scoped, but geo coordinates are intentionally omitted with a code comment ("Geo coordinates not confirmed — left out") — a defensible conservative choice given they're not owner-confirmed, but it means the schema is missing a recommended property (5-decimal-precision geo is explicitly called out as a "recommended" LocalBusiness property). Once the physical address is confirmed usable for GBP verification, geocoding it (e.g., via a geocoding API, matched against what will eventually be entered in GBP) and adding geo should follow, not precede, GBP setup — don't guess coordinates.

6. No openingHoursSpecification anywhere (live or repo) No opening hours are declared in schema, and I found no visible hours copy on the pages read. For an event-catering business without walk-in hours this is lower-urgency than for a storefront, but if there are defined business hours for phone/WhatsApp inquiries, adding openingHoursSpecification (or explicitly modeling this as a by-appointment/SAB business without standard hours) helps completeness.

7. No Service schema per offering (Bodas, Corporativo, Reuniones Familiares) bodas-reales.astro, corporativo-business.astro, and reuniones-familiares.astro are genuinely dedicated, differentiated service pages (good — per Whitespark 2026 this is the #1 local organic ranking factor and #2 AI-visibility factor) but only carry FAQPage schema, not Service entities with their own areaServed/provider linking back to the business. Adding Service markup per offering (name, areaServed, provider: {"@id": "...#business"}) would strengthen this further.

MEDIUM

8. /privacidad and /cookies omit the physical address (repo state) In the repo checkout, privacidad.astro's "Responsable del Tratamiento" section lists only phone and website, no street address — same for /cookies. Not a contradiction (nothing wrong is stated), but it's a missed reinforcement opportunity on two more indexable-by-Google pages, and for a Spain-based business, LSSI/RGPD "Responsable del Tratamiento" sections conventionally do include the operating address. Tied to finding below.

9. /aviso-legal is explicitly provisional, missing NIF/CIF and registered address The page self-declares ("Aviso provisional pendiente de completar") that legal identity (NIF/CIF, domicilio social) is not yet finalized. This is a legal-compliance gap more than a pure local-SEO one, but it also means there is currently no page on the site carrying the formal registered-entity address that would need to match GBP's business-verification documents later. Flagging so it's on the radar before GBP verification is attempted (GBP verification frequently requires documents matching the on-site legal entity/address).

10. astro.config.mjs sitemap filter excludes /cookies and /privacidad but not /aviso-legal Minor technical-SEO note found while reading: /aviso-legal has robots: noindex,follow but is not excluded from the sitemap generator, so it will appear in sitemap-index.xml despite being noindexed — inconsistent with how /cookies and /privacidad are handled. Not a local-SEO scoring factor but cheap to fix alongside the other config changes.

11. No Tier-1 citation presence verifiable No outbound links to Yelp, TripAdvisor, Google Maps place pages, or Spain-relevant directories (e.g., Páginas Amarillas, Bodas.net, Zankyou — all commonly used by Spanish wedding/catering vendors) exist anywhere in the codebase, and none could be verified live without paid tooling. Given catering/weddings is the vertical, Bodas.net and Zankyou are more relevant citation targets for this business than the generic Yelp/BBB pair — worth prioritizing once GBP exists.

LOW

12. Locale signals are solid — <html lang="es-ES"> and og:locale: es_ES are consistent on both live and repo. No action needed, listed here only because it was explicitly in scope to check and it passes.

---

Local SEO Score: 22 / 100 (live site) — repo checkout, if deployed as-is, would score materially higher (~34/100), see caveat

This score reflects the live site (www.mnqeventos.es), since that's what Google is actually crawling today. The repo checkout has a partial fix in progress (address present, areaServed present) but still ships the invalid schema @type and the wrong canonical domain in every config file I read, so it should not be treated as "done" either.

Dimension	Weight	Live score	Weighted
GBP Signals	25%	5/100	1.25
Reviews & Reputation	20%	30/100	6.0
Local On-Page SEO	20%	30/100	6.0
NAP Consistency & Citations	15%	15/100	2.25
Local Schema Markup	10%	15/100	1.5
Local Link & Authority Signals	10%	15/100	1.5
Total			~22 / 100

Notes on the two lowest-context dimensions:

• GBP Signals (5/100): No Maps embed, no place reference, no review widget, no GBP-sourced photos anywhere — expected and acknowledged, since GBP hasn't been created yet. Scored low because the checklist asks for on-page evidence of GBP integration, and there is none, not because the business did anything wrong by not having GBP yet.
• Reviews & Reputation (30/100): Hardcoded testimonials with decorative 5-star UI exist on the homepage and /bodas-reales (repo-confirmed; not independently re-verified live within the turn budget), but none are marked up as Review/aggregateRating schema, none are sourced from or attributable to a live review platform, and there is no review velocity data (no GBP yet). Counted as a trust signal, not a verifiable review asset.

---

What already works well

• Phone number consistency is genuinely solid, live and in repo: +34 678 17 15 13 (display) / tel:+34678171513 (href) is identical across home, /contacto, /privacidad, /cookies on the live site.
• Dedicated service pages exist for the three core offerings (Bodas, Corporativo, Reuniones Familiares) rather than one generic services page — this is directionally correct per current local-SEO best practice, it just needs schema to match.
• Locale/language signals are correct and consistent (es-ES, es_ES) across the whole site.
• The repo checkout is already ahead of production on address and areaServed in schema — once deployed (with the domain and @type also fixed), several of the findings above resolve at once.
• The catering business model (base address + event-location service) is a legitimate hybrid, and the areaServed approach in the repo (City: Málaga + AdministrativeArea: Provincia de Málaga) is appropriately scoped rather than overreaching.

---

Top 10 Prioritized Actions

1. [Critical] Fix every hardcoded reference to mnqcatering.com (canonical tag, og:url, JSON-LD url, footer/contacto links, astro.config.mjs site, robots.txt, llms.txt) to www.mnqeventos.es, and deploy to production. Verify live afterward — do not assume the repo fix is sufficient until it's actually served.
2. [Critical] Deploy the address/PostalAddress/areaServed fix that's in the repo checkout but not live — currently the live site has zero address signal anywhere.
3. [Critical] Replace the invalid @type: "CateringService" with a schema.org-valid type. Verify whatever replacement is chosen (including the coordinator-mentioned CateringBusiness) against Google's Rich Results Test before considering this closed — don't trade one invalid type for another.
4. [High] Fix the plural/singular brand name inconsistency in SiteHeader.astro and SiteFooter.astro (alt/aria-label) to match the singular form used everywhere else.
5. [High] Add Service schema (with areaServed and provider back-reference) to each of the three offering pages.
6. [High] Once the primary fixes are deployed and stable, create and verify the Google Business Profile using the exact corrected name/address/phone/URL — this is the acknowledged next external step, not a site defect.
7. [Medium] Add the operating address to /privacidad's "Responsable del Tratamiento" section and to /cookies for reinforcement.
8. [Medium] Finalize /aviso-legal with NIF/CIF and registered address before attempting GBP verification, since verification documents typically need to match.
9. [Medium] Exclude /aviso-legal from the sitemap (or remove its noindex) to make sitemap/robots directives internally consistent.
10. [Low] Once GBP exists, pursue vertical-relevant citations (Bodas.net, Zankyou, Google Maps) rather than generic Yelp/BBB, which are less relevant to a Spain-based wedding/events caterer.

---

Limitations disclaimer

• Domain confusion mid-audit: the audit began against mnqcatering.com, confirmed non-resolving via two independent DNS paths (local resolver NXDOMAIN, and WebFetch's own getaddrinfo ENOTFOUND), then was redirected mid-task to the real live domain www.mnqeventos.es per coordinator/WHOIS confirmation. All "LIVE" findings above come from directly fetching www.mnqeventos.es in this session; I did not have time within the turn budget to re-check every page (e.g., /nosotros, /bodas-reales, /corporativo-business, /reuniones-familiares were read from the repo but not re-fetched live) — treat those as REPO-sourced only.
• Could not verify the coordinator-asserted "fixed" state (domain + CateringBusiness type) directly — no uncommitted diff for those files existed in this checkout (git diff on src/middleware.ts, src/layouts/MainLayout.astro, astro.config.mjs was empty), so that fix lives elsewhere (different session/worktree) and is reported as unconfirmed, not verified.
• No GBP, no paid tools: GBP doesn't exist yet, so review velocity, GBP category, Maps pack position, and DataForSEO/live-SERP checks are all inherently unavailable — not a site defect, just out of scope for on-page analysis.
• Citation presence (Yelp/BBB/Bodas.net/etc.) was checked only by absence of outbound links in source/HTML, not via direct site: searches or crawls of those third-party platforms — a false negative is possible if the business is listed there without the live site linking to it.
• Turn-limited pass: given the mid-task domain correction and remaining turn budget, I prioritized the highest-signal checks (canonical/NAP/schema across home + 3 legal/contact pages) over exhaustively re-fetching every service page live.