# 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.