# Visual / Above-the-Fold Audit — mnqcatering.com

## Summary

The audit target, `https://www.mnqcatering.com`, **does not resolve**. No visual, above-the-fold, mobile-rendering, or CTA/overlap analysis could be performed because the site is unreachable — this is not a tooling limitation, it is a state of the live domain itself. No screenshots were captured and none of the requested visual assessments (CTA clarity, tap-target sizing, layout shift, WhatsApp/cookie-banner overlap) could be verified. Do not treat the absence of findings below as "no issues" — it means "not observable."

## Verification performed

Playwright/Chromium was successfully installed and configured in this session (in an isolated venv), so tooling was not the blocker. Navigation to `https://www.mnqcatering.com` failed with `net::ERR_NAME_NOT_RESOLVED`. This was cross-checked independently of the browser:

- `nslookup www.mnqcatering.com` (local resolver) → `NXDOMAIN`
- `dig mnqcatering.com @8.8.8.8` and `@1.1.1.1` (public resolvers, bypassing any local/sandbox DNS) → `NXDOMAIN`
- `whois mnqcatering.com` → **"No match for domain 'MNQCATERING.COM'"** (Verisign registry has no registration record for this domain at all — this is not "DNS not yet propagated," it means the `.com` is currently unregistered/available)

This confirms the failure is a real domain/DNS state, not a sandbox network artifact.

## Codebase cross-check

The repository is configured with `www.mnqcatering.com` as the intended canonical host:

- `astro.config.mjs`: `site: 'https://www.mnqcatering.com'`
- `src/middleware.ts`: `CANONICAL_HOST = 'www.mnqcatering.com'`, with a comment noting the site was "undesirably mirrored at mnqeventos.es (same content, no redirect at the DNS/hosting level)" and enforcing app-layer redirects to the `.com` host for any other incoming host (including `mnqeventos.es`, `www.mnqeventos.es`, and the bare `mnqcatering.com` apex)

This means the middleware's entire redirect strategy currently funnels traffic toward a domain that is not registered — if that middleware is live anywhere, it is actively redirecting visitors to a dead destination.

### `mnqeventos.es` (the alternate host referenced in the code)

- `dig mnqeventos.es @8.8.8.8` → resolves to `169.58.117.246` (domain is registered and has DNS records)
- An HTTP reachability check from this sandbox to `mnqeventos.es` failed at the network layer (could not resolve/connect from this specific execution environment, despite public DNS resolving it), so I could **not** confirm `mnqeventos.es` is actually serving the live site, nor capture screenshots of it. This is a sandbox network-egress limitation for that particular check, distinct from the `mnqcatering.com` finding, which is a confirmed WHOIS/registry-level absence.

## Findings

| # | Severity | Evidence | Recommendation |
|---|----------|----------|-----------------|
| 1 | **Critical** | `whois mnqcatering.com` → "No match for domain 'MNQCATERING.COM'"; `dig` against 8.8.8.8 and 1.1.1.1 both return NXDOMAIN | The canonical domain the entire site (config, middleware, sitemap, canonical tags) is built around is not currently registered. Register/renew `mnqcatering.com` immediately, or confirm with the registrar whether this is an expiry lapse. Until resolved, the site has zero organic visibility on its intended domain — this supersedes every other SEO/visual concern audited elsewhere in this project. |
| 2 | **High** (unverified, code-derived) | `src/middleware.ts` redirects all non-canonical hosts (including `mnqeventos.es`) to `www.mnqcatering.com` with a 301 | If this middleware is deployed and `mnqeventos.es` is the domain actually receiving traffic, that traffic is being 301-redirected to an unregistered domain — a hard dead end for users and a guaranteed crawl error for search engines. Verify current production deployment target before doing anything else. |
| 3 | Info | N/A — no page could be loaded | All requested visual checks (above-fold CTA visibility, mobile tap-target sizing ≥48x48px, layout-shift risk, WhatsApp floating button vs. cookie-banner overlap) are **unverified**, not "passed." Re-run this audit once the domain resolves. |

## Score

**0 / 100** — reason: primary audit target domain does not resolve (unregistered per WHOIS). No page content was reachable, so no visual/UX quality can be assessed or scored on its merits; a non-resolving domain is a full blocker for any user or crawler reaching the site.

## What already works well

Cannot be assessed — no page rendered. The one positive observation available from static inspection is that the **codebase's intent** is coherent: a single canonical host is configured consistently across `astro.config.mjs`, `MainLayout.astro`, and `middleware.ts`, and there's already institutional awareness of the `mnqeventos.es` duplicate-content risk (captured in code comments and a prior "redirect non-canonical domains" commit). The problem is not the code's design — it's that the domain the code assumes is live is not currently registered.

## Next step

This is a domain-registration/DNS-infrastructure issue, outside the scope of code or content changes. Resolve domain registration first, then re-run this visual audit (desktop 1440px / mobile 390px screenshots of homepage and `/bodas-reales`, CTA/tap-target/overlap checks) against a confirmed-live host.