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

Technical SEO Audit — MNQ Catering y Evento

Audited live site: https://www.mnqeventos.es/ (confirmed canonical/production domain — see Finding #1) Date: 2026-09-15 Method: DNS (dig, WHOIS), curl (headers/status/redirects), HTML source inspection. No JS rendering / Lighthouse run performed (out of scope).

Summary

The domain originally given for this audit, mnqcatering.com / www.mnqcatering.com, does not exist — confirmed via WHOIS ("No match for domain MNQCATERING.COM") and authoritative DNS (NXDOMAIN). This was corrected mid-audit by the coordinator: the real, live, production domain is https://www.mnqeventos.es/ (bare apex mnqeventos.es has no A record — only the www host resolves and serves).

The codebase was fixed in this session (commit a6692b7, working tree at audit time) to set CANONICAL_HOST = 'www.mnqeventos.es' in src/middleware.ts and site: 'https://www.mnqeventos.es' in astro.config.mjs. This fix is not yet deployed: every live page fetched during this audit still emits canonical tags, the sitemap, robots.txt, JSON-LD url, and og:url/og:image pointing at www.mnqcatering.com — a domain that cannot resolve. This is the single highest-priority issue in the audit.

Findings

1. [Critical] Declared canonical domain (www.mnqcatering.com) does not exist in DNS/WHOIS

Evidence:

$ whois mnqcatering.com
No match for domain "MNQCATERING.COM".

$ dig www.mnqcatering.com A +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

Recommendation: Confirmed non-bug in the audit sense (per coordinator) — the domain was never registered. Action item is organizational, not technical: either register mnqcatering.com and point it at the same infrastructure with a 301 to www.mnqeventos.es, or fully scrub any remaining reference to it (marketing collateral, external backlinks, business cards, Google Business Profile, etc.) since it's a dead domain that currently returns nothing.

2. [Critical] Production is still serving the pre-fix build — every canonical/sitemap/structured-data reference points to the non-existent domain

Evidence (all fetched live from https://www.mnqeventos.es/ on 2026-09-15):

• Canonical tags on all 9 pages, e.g.: <link rel="canonical" href="https://www.mnqcatering.com/"> <link rel="canonical" href="https://www.mnqcatering.com/aviso-legal">
• robots.txt:

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

• sitemap-index.xml → <loc>https://www.mnqcatering.com/sitemap-0.xml</loc> → sitemap-0.xml lists 7 URLs, all on https://www.mnqcatering.com/...
• JSON-LD (CateringService): "url":"https://www.mnqcatering.com"
• OpenGraph: og:url and og:image both on https://www.mnqcatering.com/...
• The application-layer redirect middleware (which should force any non-canonical Host to the canonical one) is not firing in production: https://www.mnqeventos.es/ returns 200 directly instead of a 301 — consistent with the live deployment predating the a6692b7 fix, since that fix only changed which host is canonical, not whether the middleware runs.

Repo state confirms the fix exists in source but hasn't shipped:

src/middleware.ts:3:const CANONICAL_HOST = 'www.mnqeventos.es';
astro.config.mjs:6:  site: 'https://www.mnqeventos.es',

$ git log --oneline -3
a6692b7 fix(seo): correct canonical domain to www.mnqeventos.es
0e242a6 docs(seo): add search-engine publication and local SEO checklist
5741e68 fix(seo): redirect non-canonical domains to www.mnqcatering.com

Impact: Every canonical signal Google/Bing can currently read is unreachable. Search engines will either ignore the canonical hint entirely (falling back to the URL actually crawled, www.mnqeventos.es) or, worse, treat it as a soft error during indexing. The sitemap is effectively useless since its URLs 404-by-DNS. This blocks clean re-indexing under the correct domain. Recommendation: Deploy the current master/working-tree build immediately. Post-deploy, re-verify: canonical tags, sitemap URLs, robots.txt Sitemap: line, JSON-LD url, and og:url/og:image should all read https://www.mnqeventos.es/.... Then submit the updated sitemap in Search Console/Bing Webmaster Tools and request re-indexing of all 7 indexable URLs.

3. [High] No security headers on any response

Evidence:

$ curl -s -D - -o /dev/null --http1.1 https://www.mnqeventos.es/nosotros
HTTP/1.1 200 OK
Alt-Svc: h3=":443"; ma=2592000
Content-Type: text/html
Date: Tue, 15 Sep 2026 07:14:49 GMT
Transfer-Encoding: chunked

No Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Content-Security-Policy, Referrer-Policy, or Permissions-Policy header on any of the 9 pages or robots.txt/sitemap-index.xml. No Content-Encoding returned even when requesting Accept-Encoding: gzip, br, deflate — responses are served uncompressed (or the header is stripped at the edge; either way it's not observable from outside). Recommendation: Add at minimum Strict-Transport-Security: max-age=31536000; includeSubDomains, X-Content-Type-Options: nosniff, X-Frame-Options: DENY (or CSP frame-ancestors), and a baseline CSP. These aren't primarily ranking factors but HSTS absence is a real security/trust gap, and Google's security-signals tooling (and some AI crawlers) do surface missing headers. Also verify/enable br or gzip compression at the CDN/edge — it affects transfer time and thus LCP on slower connections.

4. [Medium] Trailing-slash URL duplication not canonicalized at the redirect layer

Evidence:

$ curl -s -o /dev/null -w "%{http_code}\n" https://www.mnqeventos.es/aviso-legal
200
$ curl -s -o /dev/null -w "%{http_code}\n" https://www.mnqeventos.es/aviso-legal/
200

Both variants return 200 directly (no redirect either way), yet the sitemap lists the trailing-slash form (https://www.mnqcatering.com/aviso-legal/) while the page's own canonical tag declares the no-slash form (https://www.mnqcatering.com/aviso-legal) — the two signals disagree with each other, independent of the domain issue in Finding #2. Recommendation: Pick one form (recommend no trailing slash, matching the existing canonical tags) and 301-redirect the other at the middleware/edge level; make sure the sitemap generator emits the same form as the canonical tags.

5. [Info/Pass] Meta robots correct across all 9 pages

Evidence: index,follow on /, /nosotros, /bodas-reales, /corporativo-business, /reuniones-familiares, /contacto; noindex,follow on /cookies, /privacidad, /aviso-legal. The sitemap correctly excludes the three noindexed legal pages (7 URLs listed, matching the 6 index,follow pages + none of the 3 noindex pages — actually 7 = 6 main + apex counted once; legal pages correctly absent). No issue — this is exactly the intended pattern.

6. [Info/Pass] No 404s or broken internal links found

Evidence: All 9 requested paths return 200. All href="/..." internal links extracted from all 9 pages resolve to one of those same 9 known paths (no dead links, no orphaned nav targets). A deliberately invalid path returns a real 404:

$ curl -s -o /dev/null -w "%{http_code}\n" https://www.mnqeventos.es/this-page-does-not-exist-xyz
404

7. [Info/Pass] TLS certificate valid, but scoped only to the real domain

Evidence:

subject=CN=www.mnqeventos.es
issuer=C=US, O=Let's Encrypt, CN=YR2
notBefore=Aug 15 10:48:30 2026 GMT
notAfter=Nov 13 10:48:29 2026 GMT
X509v3 Subject Alternative Name: DNS:www.mnqeventos.es

Valid, auto-renewing (Let's Encrypt ~90-day cert, well within window). SAN correctly does not include mnqcatering.com (expected, since that domain doesn't exist — not a cert misconfiguration). No action needed beyond normal renewal monitoring.

8. [Info/Pass] Core Web Vitals signals look solid from source inspection

Evidence: Hero/LCP image has loading="eager" fetchpriority="high" decoding="async" with explicit width/height; all other images are loading="lazy" with explicit dimensions (protects CLS); web fonts use the preload + onload swap-to-stylesheet pattern (avoids render-blocking); the one third-party script (analytics, umami.qreastech.com) is async defer; zero inline blocking <script> tags; homepage HTML is a lean 25KB. No obvious CWV red flags from static inspection — a real Lighthouse/CrUX run is still recommended to confirm actual LCP/INP/CLS values, but nothing in source suggests a problem.

9. [Not applicable / blocked] IndexNow

indexnow.txt/key file not found (404). Given Finding #2, implementing IndexNow now (while canonical URLs point at a dead domain) would be counterproductive — pings would announce URLs on the wrong host. Recommendation: implement IndexNow only after Finding #2 is deployed and re-verified, submitting https://www.mnqeventos.es/... URLs.

Redirect Behavior Matrix

Request	Result
http://mnqeventos.es/ (bare, http)	DNS: NOERROR, 0 answers — apex has no A record, connection fails
https://mnqeventos.es/ (bare, https)	Same — apex does not serve
http://www.mnqeventos.es/	301 → https://www.mnqeventos.es/ (HTTP→HTTPS enforced, good)
https://www.mnqeventos.es/	200 direct (no further redirect — this is the live site)
http(s)://mnqcatering.com/, http(s)://www.mnqcatering.com/	Cannot resolve — domain not registered (Finding #1); not a redirect issue

The canonical-host middleware described as "just shipped" only redirects away from www.mnqcatering.com/mnqeventos.es (bare) to the CANONICAL_HOST constant — it was never expected to make the bare mnqeventos.es apex resolve (that's a DNS-level gap, not something app middleware can fix; the apex needs its own A/AAAA record or a redirect at the DNS/registrar level if traffic to the bare domain is expected).

Score: 58 / 100

What already works well: page-level fundamentals are solid — correct index,follow vs noindex,follow split, no broken internal links or unexpected 404s, valid and current TLS certificate, and CWV-relevant markup (image dimensions, lazy-loading, non-blocking fonts/scripts) all look properly implemented in the Astro source. The domain-identity fix has already been correctly authored in code.

What's dragging the score down: the fix isn't deployed, so right now every single indexing signal the site emits (canonical, sitemap, robots.txt sitemap pointer, JSON-LD, OpenGraph) points at a domain that returns NXDOMAIN — which for a live production site is as severe as having no canonical at all — compounded by a total absence of security headers.