Jameel Fragrance: Public Audit to Verified Reconciliation to Measured Improvement

Overview

This case study follows one real audit engagement — for jameelfragrance.com, a paying Opsome client, published with their explicit permission — through four phases: a public-signal audit, a verified reconciliation against the client’s own private data, a scoped remediation plan, and a measured before/after. Each phase below is filled in only once that phase’s real work is complete. Nothing here is a projection or an estimate presented as a result.

Status as of 24 August 2026: Phase 1 refreshed against an upgraded audit methodology (see note below). Phase 2 (verified-tier reconciliation, including the ecommerce tier and final report assembly) and Phase 3 (1-month remediation plan) below still reflect the 19–23 August engagement and have not yet been re-run against the refreshed Phase 1 — that reconciliation is the next step, not yet done.

A note on the refresh: ai-visibility-skills shipped a new V3 scoring methodology (a mechanical 6-pillar, 0–100 rubric replacing the old unscored “partially ready” verdict) on 21 August 2026, two days after this engagement’s original Phase 1 run. Re-running Phase 1 against the upgraded pack on 24 August surfaced real findings the original pass missed. At least one — both product category pages returning HTTP 500 — is plausibly a live regression, though the exact break date isn’t known; the others look more like gaps in what the original pass tested (a staging-domain leftover it didn’t happen to check, a crawler user-agent it didn’t test) rather than confirmed new breakage. Every original finding was independently re-verified, not assumed to still hold: none of them turned out to be wrong, but three new, more urgent issues sit ahead of them now.

Phase 1 — Public AI-visibility audit

A public-signal-only audit run with ai-visibility-skills against jameelfragrance.com on 24 August 2026 (refreshed from an original 19 August 2026 run, after the pack’s V3 scoring methodology shipped) — crawler access, sitemap discovery, structured data, content extractability, and citation readiness, using only what’s visible without any client-granted access.

Overall: 64/100 — needs improvement. Six-pillar breakdown: Discovery 60, Technical Accessibility 70, Machine Understanding 55, Answer Readiness 70, Trust & Authority 65, Agent/Action Readiness 60.

Critical — new, and more urgent than anything below

• Both product category pages return HTTP 500. /product-category/attar/ and /product-category/perfumes/ — the store’s only two categories — both serve a WordPress “critical error” page instead of a product grid. Both are still listed in the sitemap with a 5 August lastmod — 14 days before the original audit, so this could have already been broken at the time of the original Phase 1 run and simply wasn’t checked, or broken any time since; the exact break date isn’t known either way. Category-level browsing is dead either way; the storefront’s /shop/ catalog page itself still works, so this blocks browsing by category specifically, not all product discovery.
• The homepage’s main navigation, og:image, and JSON-LD ImageObject all point at a dead external staging domain (aaz.kxe.temporary.site, which doesn’t even complete a TLS handshake) — very likely a leftover artifact from a WordPress staging/migration tool that was never cleaned up, and very likely all ten references tracing back to one unresolved variable, though neither is confirmed beyond the pattern being consistent with that explanation. This breaks two nav links, the page’s social-share preview image, and the structured-data image claim.
• Amazonbot is blocked with a 403 at the edge/WAF layer, while GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and CCBot all get a clean 200 on the identical URL. robots.txt has no disallow rule for it — this is an infrastructure-level block invisible to a robots.txt read alone.

Critical — unchanged from the original audit

• The public FAQ page (/faq/) is live, indexable, placeholder Lorem Ipsum content. “What does LOREM mean?” is answered with dummy Latin filler text — the WordPress FAQ template was never filled in with real content before publishing. Any AI agent or customer reading this page gets nothing usable, and worse, could plausibly quote the placeholder as if it were a real answer.
• No Product/Offer structured data anywhere. Real prices are present in raw HTML (e.g. a ₨950.00 – ₨3,500.00 range on the Oud ul Badr product page) and are fully server-rendered — not JS-blocked — but none of it is exposed as JSON-LD. AI systems relying on structured data rather than free-text parsing cannot reliably extract price, SKU, or availability for any product.
• No return or refund policy exists anywhere on the site. Still 404 across every common return/refund URL pattern checked, and not present in the sitemap’s page list either.

Important

• No meta description on the homepage or the product pages checked.
• The homepage has no <h1> at all — a WordPress “hide page title” setting removed it site-wide on the entry page.
• Organization schema exists (via Yoast) but is minimal: name, url, logo only — no contactPoint, sameAs, or address, despite a phone number, email, and social links being present in the page footer.
• The only published contact is a Gmail address (jameelfragrance@gmail.com), not a branded domain email — a weaker identity signal for AI citation of business legitimacy.
• The site footer reads “@2024 - Jameel Fragrance” — a stale copyright year, now two years out of date rather than one.
• New: the site’s 26 indexable blog posts (index, follow) are entirely off-topic theme-demo filler (e.g. “Curtain Bangs”), authored by a generic admin account with scrambled placeholder body text — diluting the entity/topical signal for any AI system trying to determine what this business actually sells. (“Indexable” isn’t the same as “actually indexed” — the FAQ page above is also index, follow and Search Console reports it as not indexed, so this is a citation-availability signal, not a confirmed indexing outcome.)
• New: 7 of the 30 page-sitemap URLs are broken leftover theme-demo pages (home-v5 through home-v11), all returning 500 — crawl-budget noise the original pass’s summary doesn’t indicate it checked for at the individual-entry level.
• New, cosmetic: robots.txt is served as text/html instead of text/plain — parses fine regardless, not a functional block.

Reprioritized, not reversed

• /privacy-policy/ still 301-redirects to /privacy-policy-2/ — but the destination itself is stable, self-canonical, and indexable, so under the refreshed methodology’s rubric this now scores as a hygiene/naming issue rather than a citation-blocking one. The redirect exists either way; only its severity classification changed.

Ready

• AI crawler access is clean for every named bot except Amazonbot (see above): GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and CCBot all receive genuine 200 responses on the homepage.
• Content is fully server-rendered (WordPress/WooCommerce/Elementor) — page text and prices are present in the raw HTML response, not hidden behind client-side JavaScript. This holds even for the two now-broken category pages, which fail at the server, not the client-rendering layer.
• sitemap_index.xml is structurally valid and covers 8 content types — though see above: the sitemap’s overall structure is healthy, its individual listed entries are not all reachable.
• llms.txt is real (Yoast-generated, served as text/plain), not a JS-shell false positive.

Commerce protocol readiness

Originally checked via a private Opsome capability (commerce-protocol-readiness, part of the managed audit offering); re-probed on 24 August via ai-visibility-skills’ own public commerce-protocol-discovery skill, live and not assumed unchanged: jameelfragrance.com still has no agentic-commerce protocol support — .well-known/ucp (UCP) and .well-known/agent-card.json (A2A) both return 404; no MCP endpoint was discoverable to probe; no products.json/catalog feed exists. Only a standard WordPress REST API (wp-json) is discoverable, which is CMS tooling, not a commerce/agent protocol. This is a discovery-only check — full protocol/action-readiness scoring and remediation is a separate capability, not run here. This is a conventional WooCommerce store with no agent-assisted-checkout ambitions signaled anywhere — expected for its scale, and not treated as a blocker.

Phase 2 — Verified audit (private data reconciliation)

Note: this phase reconciles against the original 19 August Phase 1 findings — it has not yet been re-run against the 24 August refresh above. The new critical items (broken category pages, dead staging-domain references, the Amazonbot block) are not yet reflected in the reconciliation below; that re-reconciliation is planned as a follow-up, not done here.

The phase 1 findings reconciled against jameelfragrance.com’s own private data — GA4, Search Console, and PageSpeed/CrUX field data — on 19 August 2026, using the verified-audit methodology (described in a companion blog post; the underlying pack is part of a managed offering, not open-sourced). Private data reprioritizes which phase 1 findings matter most; it never overrides a phase 1 correctness finding.

A new finding private data alone could surface

GA4 has no ecommerce tracking configured at all. Over the last 28 days, only basic events fire (page_view, session_start, first_visit, scroll, form_start) — there is no view_item, add_to_cart, begin_checkout, or purchase event anywhere. The “0 conversions” figure in GA4 is a measurement gap, not evidence of zero sales. This is invisible from any public-signal audit; it’s arguably the single most consequential finding in this engagement, because it means the client can’t measure conversion rate, cart abandonment, or revenue attribution today — independent of any content or schema fix.

Reconciliations against phase 1 findings

• FAQ Lorem Ipsum page — reprioritized, not downgraded. Search Console’s URL Inspection API reports /faq/ as “URL is unknown to Google” — it is not indexed, so it isn’t currently reaching people through Google Search or Google AI Overviews. But it remains directly fetchable by AI crawlers (GPTBot/ClaudeBot/PerplexityBot all returned genuine 200s in phase 1), which don’t depend on Google’s index to read or cite a page. Net: the Google Search exposure risk is lower than it looked in phase 1; the direct-AI-crawler citation risk is unchanged.
• Missing Product schema — reprioritized upward. Search Console shows real, existing query volume with price intent already reaching the site — e.g. “tariq jameel perfume price in pakistan” (38 impressions, average position 2.8 over 28 days). This isn’t hypothetical demand: people are already searching with purchase intent and finding pages that have no structured price/availability data to serve a confident answer or rich result from.
• No return/refund policy — cannot be reconciled with current data. With no ecommerce events configured, GA4 has nothing to confirm or contradict about whether this gap is costing completed purchases. Disclosed explicitly as an access/data limitation, not silently dropped.
• “Server-rendered, ready” (phase 1) — confirmed, with a caveat. Search Console’s URL Inspection confirms the homepage is indexed (PASS, “Submitted and indexed,” last crawled 19 August 2026) — a direct confirmation, no reprioritization needed. Mobile PageSpeed Insights shows a lab performance score of 0.58, with LCP at 4.2s and CLS at 0.244 — both outside “good” Core Web Vitals thresholds. No real-user CrUX field data exists yet; the site’s traffic volume (see below) is too low to populate a CrUX report, so this is lab data only, disclosed as such rather than presented as confirmed real-user experience.

Traffic scale, for context on everything above

GA4’s 28-day totals: 22 sessions, 43 pageviews, 18 users, 50% bounce rate — split 16 sessions from Organic Search and 6 Direct. This is a very low-traffic site. It doesn’t change the correctness of any phase 1 finding, but it reframes their business impact: the content/schema/policy gaps above are real and worth fixing, but the more foundational constraint at this scale is limited demand capture, not a large existing audience being poorly served.

Sources not supplied

Per the verified-audit methodology’s disclosure requirement: no Bing Webmaster Tools export and no server log excerpt were supplied for this audit. Bing/Copilot-specific indexing and IndexNow submission status remain unverified; actual crawler behavior (as opposed to simulated curl fetches) is unconfirmed by real log data.

Ecommerce tier (additive, not a replacement for phases 1–2)

jameelfragrance.com is a WooCommerce storefront, so the verified-audit methodology’s ecommerce wrapper applies on top of phases 1–2 above — not instead of them. Per the methodology’s own intake step, both commerce-specific sources were asked about explicitly on 23 August 2026, not assumed unavailable:

• Order data export: supplied. A read-only WooCommerce REST API key was generated by the client and used for a live, read-only pull — no order was created, modified, or acted upon.
• Support-ticket-category export: not supplied. The client has no consolidated ticket system to export from. Disclosed here explicitly, per the methodology’s disclosure rule — the policy/support-gap findings in phase 1–2 above (no return/refund policy, Gmail-only contact) remain based on public and verified signals only, not confirmed support-ticket volume.

Order data findings (live pull, 23 August 2026):

• 8 orders exist on the site, all-time. This is not a 28-day or 90-day window — it is the store’s entire order history since launch. The most recent order was placed 14 March 2026; the one before that, 13 September 2025 — a roughly six-month gap between the two most recent orders.
• Status distribution: 6 processing, 2 completed, 0 cancelled, 0 refunded, 0 failed. With only 8 orders total, a cancellation/refund rate isn’t a meaningful statistic yet — 0 out of 8 is disclosed as the raw count, not extrapolated into a percentage that would imply more data than exists.
• Zero agent- or API-initiated orders. Every order’s created_via field reads checkout — the standard human web-checkout flow. None originated from an API, admin action, or automated channel.

Reconciliation against protocol/action-readiness (concrete, not just cited): Phase 1’s commerce-protocol-readiness check was actually run against jameelfragrance.com, not merely referenced — it found no UCP, A2A, or MCP discovery endpoints (all 404). The order data above is consistent with that finding: with no agentic-checkout protocol surface deployed, zero agent-initiated orders is exactly what real order data should show, and it does. Both sources — a live protocol probe and a live order ledger — independently point to the same conclusion: this store has no agent-checkout capability today, deployed or otherwise attempted.

What this dimension does not tell you: 8 orders all-time is a business-scale fact, not a technical-readiness finding — it doesn’t reprioritize any phase 1/2 finding upward or downward on its own. It does contextualize them: at this order volume, the content/schema/policy gaps identified in phases 1–2 are unlikely to be the primary constraint on the business today; demand generation is.

Final assembled report

The public tier, verified tier, and ecommerce tier above are merged here into one ranked view — no finding above is re-tiered or re-tagged in this merge, only reordered by business impact.

Tier-2 access declared: Search Console (supplied), GA4 (supplied), PageSpeed/CrUX (supplied), Bing Webmaster Tools (not supplied), server logs (not supplied). Order data (supplied), support-ticket categories (not supplied). No pasted AI-engine answer text was supplied for this audit — AI-citation mention/citation classification is not available, not inferred as absent.

Ranked blockers, by business impact using real data — not a generic severity list:

1. No ecommerce tracking in GA4. Ranked first because every other finding’s business-impact estimate downstream of this audit is itself unverifiable without it — the client cannot currently measure whether fixing anything below actually moves a real number.
2. Live Lorem Ipsum FAQ page. Ranked second, not first, because Search Console confirms it isn’t Google-indexed (lower reach than a public-only audit would assume) — but it stays this high because it’s still directly fetchable by every major AI crawler, and a live placeholder answer is a worse outcome than no answer at all.
3. Missing Product/Offer schema. Ranked third specifically because Search Console shows real, existing price-intent query volume already reaching the site (e.g. 38 impressions for “tariq jameel perfume price in pakistan”) — a public-only audit would have flagged this as a generic best practice; real query data confirms actual unmet demand sitting behind it today.
4. No return/refund policy. Ranked fourth, held below the schema gap because — per the explicit disclosure above — no ecommerce or support-ticket data exists to confirm this is actually costing completed purchases; the ranking reflects that uncertainty rather than assuming the worst case.
5. Mobile performance (LCP 4.2s, CLS 0.244). Ranked last of the flagged items — lab data only, no real-user CrUX data exists at this traffic volume, and 8 all-time orders means performance is very unlikely to be the binding constraint on the business right now.

Remediation hand-off: this audit went through the ecommerce wrapper (skill 04 ran — order data was supplied and incorporated), so per the methodology’s own routing rule, the merged findings above hand off to wakqasahmed/agentic-commerce-skills’s custom-agent-remediation-plan skill, not the general-site ai-search-remediation-plan path. That skill’s ticket format already covers agent/storefront/shared classification, action-capable risk levels, and operational controls this audit does not duplicate — the actual remediation tickets are Phase 3’s job, not this report’s.

Phase 3 — 1-month improvement plan

Built with wakqasahmed/agentic-commerce-skills’s custom-agent-remediation-plan skill, per Phase 2’s routing note — not the general-site ai-search-remediation-plan path, because this audit went through the ecommerce wrapper. Window: 24 August 2026 – 20 September 2026 (4 weeks). Every item below is classified by delivery owner (agent / storefront / shared), action mode, and risk level, with a named accountable owner and a baseline/post-change check that re-runs the same live source used in Phases 1–2 — not a re-stated intention.

Plan status: READY. None of the five items is action_capable or high risk — every item here is read-only content, instrumentation, or storefront configuration work, not an autonomous agent action on orders, payments, or customer data. That means the operational-controls set the remediation skill requires for action-capable/high-risk work (kill switches, reconciliation checks, escalation paths, etc.) does not apply to this plan — consistent with Phase 1’s finding that this store has no agentic-checkout protocol surface and no agent-checkout ambitions. If a future phase adds an action-capable capability (e.g. an agent that files return requests), that item would need its own controls before shipping.

Remediation items

1. Instrument GA4 ecommerce tracking — bucket: integration · delivery: storefront · mode: read-only · risk: low

• Owner: site technical owner (Opsome delivery engineer).
• Task: configure a WooCommerce GA4 ecommerce-tracking integration (plugin-based data-layer push, not a custom build) so view_item, add_to_cart, begin_checkout, and purchase fire into the same GA4 property used in Phase 2; verify one full test checkout end-to-end.
• Effort: ~4 hours.
• Week: 1 (no dependency on other items — scheduled first because every other item’s business-impact measurement in Phase 4 depends on this existing).
• Baseline check: Phase 2 finding — 28-day GA4 event list contains only page_view, session_start, first_visit, scroll, form_start; zero ecommerce events.
• Done when: GA4 DebugView/Realtime shows all four ecommerce events firing on a live test session, and a re-run of the same 28-day event-list query (Phase 4) shows nonzero counts for each.

2. Replace the Lorem Ipsum FAQ content — bucket: content · delivery: shared (Opsome drafts, client approves) · mode: read-only · risk: low

• Owner: client content owner signs off; Opsome drafts and publishes.
• Task: write 6–10 real FAQ entries from the site’s actual shipping policy, product range, and order process (no invented policy claims — anything not already confirmed elsewhere, like return terms, is deferred to item 4 rather than guessed here); replace the placeholder page content in WordPress.
• Effort: ~3 hours plus client review turnaround.
• Week: 1, in parallel with item 1.
• Baseline check: Phase 1 finding — /faq/ answers “What does LOREM mean?” with placeholder Latin filler.
• Done when: a live fetch of /faq/ contains zero occurrences of “lorem”/“ipsum” and every question has a real, accurate answer traceable to an existing site policy or product fact.

3. Add Product/Offer JSON-LD schema — bucket: product_knowledge · delivery: storefront · mode: read-only · risk: low

• Owner: Opsome delivery engineer.
• Task: enable/configure structured-data output for product pages (a WooCommerce-compatible schema plugin/add-on, not a hand-rolled template) so price, currency, availability, and SKU are exposed as Product/Offer JSON-LD; spot-check 5 products including Oud ul Badr.
• Effort: ~6 hours.
• Week: 2.
• Baseline check: Phase 1 finding — no Product/Offer JSON-LD anywhere; Oud ul Badr’s ₨950.00–₨3,500.00 price exists only in raw HTML.
• Done when: Google’s Rich Results Test returns a valid Product result (name, price, currency, availability) for all 5 sampled product URLs, with the schema price matching the visible on-page price exactly.

4. Publish a return/refund policy — bucket: policy · delivery: shared (client supplies terms, Opsome drafts and publishes) · mode: read-only · risk: low

• Owner: client owner (sign-off on actual terms — window, condition requirements, refund method, return-shipping cost); Opsome publishes.
• Task: request the client’s actual return terms in week 1 (longest lead time in this plan, since it depends on the client, not on Opsome’s schedule); draft a dedicated return/refund policy page once terms are confirmed; link it from the site footer and the existing shipping-policy page.
• Effort: ~2 hours drafting + ~1 hour publish, plus client turnaround time not controlled by this plan.
• Week: requested week 1, published by week 3 once terms are confirmed.
• Baseline check: Phase 1 finding — no return/refund policy exists anywhere on the site; Phase 2 — no ecommerce/support data exists to confirm purchase impact either way.
• Done when: a live fetch of the published policy URL states all four terms (window, condition, refund method, cost) in plain text, and the footer link resolves with a 200.

5. Improve mobile Core Web Vitals — bucket: workflow · delivery: storefront · mode: read-only · risk: low

• Owner: Opsome delivery engineer.
• Task: convert/compress hero and product images (WebP, explicit width/height to reserve layout space), and defer non-critical render-blocking Elementor/theme JS.
• Effort: ~8 hours.
• Week: 3–4 — scheduled last both because it’s the largest single task and because re-testing after items 2–4’s content changes avoids a false pass/fail from a page that changes again afterward.
• Baseline check: Phase 2 finding — mobile PSI lab run: score 0.58, LCP 4.2s, CLS 0.244.
• Done when: a runPagespeed call (same method as Phases 1–2) against the same homepage/product-page URLs shows LCP under 2.5s and CLS under 0.1 — Google’s “good” thresholds — compared directly against the Phase 2 baseline figures, not a generic target.

What this plan does not attempt

No item here adds agent-checkout capability, automated customer communication, or any action that writes to orders, payments, or customer records — consistent with Phase 1’s finding that this store has no agentic-commerce protocol surface and Phase 2’s finding of zero agent-initiated orders. Adding such a capability is out of scope for this remediation window and would require its own action-capable risk assessment and operational controls before shipping, not a retrofit onto this plan.

Status: scoped and ready to execute; window has not yet elapsed.

Phase 4 — Before/after results

What this will contain: the same checks from phases 1–2, re-run after the one-month remediation window, with dated evidence showing what actually changed — not a repeat of the remediation plan’s intended outcomes.

Status: not started — depends on phase 3 completing and its window elapsing.

Evidence and access

• PSI/CrUX: Google Cloud API key created, restricted to the PageSpeed Insights API, verified via a live runPagespeed call against jameelfragrance.com returning a real Lighthouse result (19 August 2026).
• GA4: a dedicated read-only service account was added as a Viewer on the client’s GA4 property (existing client-level access, no new client ask required); verified via a live runReport call returning real 28-day page-level traffic data (19 August 2026).
• Search Console: the same service account was added as a restricted user on the property; verified via a live search-analytics query (19 August 2026) and a live URL Inspection API call for both the homepage and /faq/.
• WooCommerce order data: a read-only REST API key was generated by the client (WooCommerce → Settings → Advanced → REST API, Read permission only); verified via a live, read-only GET /wp-json/wc/v3/orders call returning real order records (23 August 2026). No order was created, modified, or acted upon.
• Client permission: jameelfragrance.com has given explicit permission for this audit and its findings to be published as a portfolio case study.

Why This Matters

Most AI-visibility “audits” stop at phase 1 — a public checklist with no way to verify whether the fixes it recommends actually mattered. This case study is structured so that claim can’t be made here without evidence: phase 2 keeps public guesses and private data from contaminating each other, phase 3 commits to a specific plan before results exist, and phase 4 only reports what was actually measured after the fact.