Redesign review, full sitemap audit
You pushed a new design + new copy to zucity.org today. I crawled all 292 URLs in the sitemap (146 EN + 146 JA, perfect parity), diffed against the 2026-05-28 baseline, ran the bug-flag pass, and went deep on the 5 pages you flagged. Here is everything in one place.
Headline: the redesign is a real step forward. Strong copy throughout. Schema is comprehensive (FAQPage and HowTo on item pages now eligible for rich results). Locale parity is clean. The honest issues below are mostly small fixes you can do in an afternoon, plus one structural bug class introduced by partner-property imports.
Executive summary
What's good (lead with this)
Item 1 (ZuCity Japan Daily Access) now ships JSON-LD with FAQPage + HowTo schema. Both are Google rich-result eligible. The Daily Access page is now structured to show up as an expandable FAQ block AND a step-by-step in search results for "how to visit ZuCity" queries. Real ranking edge.
Smart redesign move. Lower entry-point friction for the "should I check this out for a day" mental crossing. The $50 sits cleanly under the $200 (Global Membership) and $25,000 (VIP) ladder rungs. The $500-$25,000 gap from yesterday's audit still exists, but Daily Access is now a stronger funnel-top.
Every English URL has a Japanese twin. Sitemap declares hreflang en/ja/x-default triangulation. robots.txt explicitly allows ClaudeBot, GPTBot, PerplexityBot, Google-Extended. This is exactly the AI-citation-ready setup we'd recommend if you came to OO asking how to build for AI search visibility.
The 2026-05-28 audit flagged item 19 as the "sleeping AI wedge" - $8 AI offering with zero JSON-LD description. The redesign now ships 53 words explaining what the credits buy. One of three bugs flagged on 2026-05-28 is fixed in the live redesign.
Bugs to fix this week
Items /items/12 (Osaka Art Residency), /13, /14, /15 (Elelfa Moshiri House Studio/Music/Workshop), /16 (Traditional Family Estate) all still emit "price":"50000000","priceCurrency":"USD" in their JSON-LD. Same bug as 2026-05-28; redesign did not touch the price field on those SKUs. This leaks into AI overviews and Google Rich Results.
https://zucity.org/en declares <link rel="canonical" href="https://zucity.org/">. This tells Google "/en is the same as /". But / actually redirects to /en. The cycle creates indexing ambiguity. Best practice: self-referential canonical (/en canonical-to /en).
next-intl or similar Next.js i18n middleware), set canonical: hreflangSelf mode for locale-prefixed pages. 5 min code edit if you have access; flag to your dev otherwise.Homepage meta description reads "A commmunity-owned neighborhood..." (three m's in "community"). This is the text Google shows under your homepage title in search results. It's not catastrophic but it reads as careless.
commmunity to community. 30 seconds.The redesign added 103 new items, almost all partner-property listings (ADDress family, Maki House, Route Inn Court, Horakuan Zen Buddhist Retreat, Finnish Log Cabin, etc.). The ETL pulling these into the catalog grabs the room title but not a description body. Result: 179 of 246 item URLs have JSON-LD descriptions of 1-5 words. Affects AI citation quality and Google rich-result eligibility on the whole partner-marketplace surface.
Bug fix: Either (a) revise the ETL to pull description body from the partner feed if available, (b) generate a templated description from address + room type + amenities ("Tatami room in {property name}, {city}, Nagano. Sleeps {N}. {amenity-list}."), or (c) omit the JSON-LD description field entirely on these listings - an empty description is worse than no description for AI citation.
Opportunity framing: These 179 thin-content surfaces are a future SEO long-tail surface. Each becomes a content opportunity for batch-generated 200-word descriptions targeting "{property name} {city} coliving" queries. The catalog scale you've shipped is real product surface; the descriptions are the bottleneck. Batch content generation against a stable template is the unlock.
The 7 original ZuCity bedrooms (5, 6, 7, 9, 10, 11) plus 9 new partner imports (Coliving Studio Kamikawa, Coliving Kurogi Farmhouse, etc.) all ship without prices in JSON-LD. Could be policy (book-by-inquiry) or could be missing data. Either way, browsers landing here see beautiful copy then have to guess what booking means.
InquireForPrice. Don't leave silent.Site structure + crawlability (clean)
Below table is the on-page audit of every priority page. All green except canonical (see Bug 2) and meta-description on a handful of secondary pages.
| Signal | Result | Verdict |
|---|---|---|
| Sitemap URL count | 292 | Healthy scale |
| Locale parity | 146 EN + 146 JA | Perfect |
| Hreflang in sitemap (en/ja/x-default) | All 292 URLs | Best practice |
| Hreflang in <head> on-page | 2 of 3 (en+ja, no x-default in head) | Minor |
| Canonical present | 292 / 292 | 100% |
| Canonical points correctly | Most pages OK, homepage broken (see Bug 2) | 1 fix |
| Noindex on public pages | 0 | All indexable |
| Missing <title> | 0 | 100% |
| Missing meta description | 4 of 292 | 98.6% |
| robots.txt AI-bot allowlist | ClaudeBot / GPTBot / PerplexityBot / Google-Extended explicitly allowed | AI-citation ready |
| TTFB (10 priority pages) | 441-511 ms | Sub-second |
i18n verdict (EN vs JA SEO setup)
You asked specifically: how does /en/ vs /ja/ affect SEO, is there a better way? Short answer: the setup is already best-practice. Long answer below.
URL pattern: locale-prefixed (correct)
You use /{locale}/path (locale-prefix). The three alternatives - {locale}.zucity.org (subdomain), zucity.jp / zucity.com (ccTLD), ?lang=ja (query param) - each have trade-offs. For a single-domain bilingual site with shared brand and shared content, locale-prefix is what Google's own i18n guide recommends. No change needed here.
Translation quality: parallel, not literal
Sample: EN homepage H1 reads "A coliving experiment an hour from Tokyo." JA homepage H1 reads "都落ちの拠点、東京から一時間。" (literal back-translation: "Countryside-fall stronghold, one hour from Tokyo"). The Japanese is doing more than translate; it uses the cultural concept of tochi-ochi (escape-to-country) which lands differently for JA readers than the English "experiment" framing. This is good practice and the kind of subtlety that matters when JA users search for things EN users would not.
JA-search intent angle
Japanese search has different long-tail patterns than English. Some specific angles your JA copy is well-positioned to capture if you commission keyword work:
- 地方移住 コミュニティ (regional migration community) - the JA equivalent of "rural coliving"
- 田舎暮らし クリエイティブ (countryside living creative) - artist/builder angle
- ポップアップシティ 日本 (popup city Japan) - direct translation works
- コモロ コリビング (Komoro coliving) - the location-specific play
- 都落ち alone - very Tokyo-bound mid-career audience
Deep keyword research with search volumes and competitor ranks for both EN and JA was scoped into this audit but DEFERRED to a follow-up session to stay under the cost cap on this round. When you want it, it is ~$3-5 of DataForSEO spend and a half-day of analysis.
Hreflang triangulation
Sitemap declares hreflang="en", hreflang="ja", and hreflang="x-default" pointing to the English version. The on-page <head> ships hreflang="en" and hreflang="ja" but NOT x-default. Sitemap-only x-default works for Google; adding x-default to the head would tighten the signal further but is not a critical fix.
Page speed (10 pages, 5 EN + 5 JA)
Quick context: I tried PSI v5 unauthenticated and got rate-limited at scale. Rather than wait for keyed access I extracted speed-signal from the already-scraped HTML: HTML payload size, JS chunk count, inline-script weight, real TTFB from curl. Numbers below are heuristic estimates - directionally correct, not Lighthouse-authoritative. If you want full Lighthouse runs with verified LCP/CLS/INP, that's a 30-min follow-up.
| Page | HTML KB | JS chunks | Inline JS KB | TTFB ms | Est-LCP 4G | Wifi |
|---|---|---|---|---|---|---|
| HOME EN | 458 | 18 | 340 | 511 | 3631 ms | 1591 ms |
| HOME JA | 385 | 18 | 271 | 462 | 3702 ms | 1572 ms |
| ZuCity EN | 324 | 19 | 283 | 452 | 2897 ms | 1363 ms |
| ZuCity JA | 256 | 19 | 217 | 452 | 3019 ms | 1393 ms |
| Neighborhood EN | 357 | 18 | 291 | 479 | 3089 ms | 1431 ms |
| Neighborhood JA | 285 | 18 | 223 | 441 | 3165 ms | 1422 ms |
| Item 3 EN | 365 | 26 | 281 | 448 | 3101 ms | 1411 ms |
| Item 3 JA | 294 | 26 | 213 | 467 | 3318 ms | 1479 ms |
| Item 1 EN | 407 | 26 | 296 | 466 | 3328 ms | 1481 ms |
| Item 1 JA | 325 | 26 | 219 | 483 | 3521 ms | 1542 ms |
What the numbers say
- TTFB is great - 441-511ms across the board. Server is fast.
- Wifi LCP is GREEN - 1.4-1.6s estimate. Anyone on home wifi or office wifi sees a snappy page.
- 4G mobile LCP is AMBER - 2.9-3.7s estimate. Just over the 2.5s Google "Good" threshold. Real users on average mobile networks experience the page as "slow but not broken."
- The cause is inline JS weight - 213-340KB of inline script per page. This is the Next.js hydration payload plus your component code. Common Next.js SSR shape; can be optimized but requires either reducing client-side JS, lazy-loading non-critical chunks, or moving more rendering server-side via React Server Components.
- JA pages are consistently lighter than EN - 256-385KB vs 324-458KB. The __NEXT_DATA__ payload is smaller on JA (0.1-0.4KB vs 3-4KB on EN). Worth investigating why EN ships more __NEXT_DATA__; if it's a translation-bundle thing, both locales could shed weight.
5 priority pages, deep review
1. Homepage (/en)
Verdict: Strong. Title is descriptive and brand-anchored. H1 is direct. 9 H2s span Neighborhood / Three pillars / Annual Popup / Builder Residency / Mountain views / Belonging / Plan your trip / Socials / Three ways in. Schema is comprehensive (WebSite + Organization + Place + ContactPoint + SearchAction + EntryPoint + PostalAddress). The 3-CTA approach (Telegram / day pass / apply long-term) is exactly the right funnel-top-mid-bottom shape.
Fixes: (1) Canonical bug per Bug 2 above. (2) Typo "commmunity" per Bug 3. (3) Optional: add x-default hreflang to head per i18n minor finding.
2. ZuCity brand page (/en/zucity)
Verdict: Functional but understructured. This page is doing double-duty as Zucity-brand-explainer AND catalog-landing. The 2 H2s ("Available Listings", "Community Events") suggest catalog-landing won; the brand-explainer angle is implicit only. JSON-LD shipping 19 types (Accommodation, Event, EventVenue, LocalBusiness, Product, Offer, Organization, etc.) is comprehensive.
Fixes: (1) Title repeats itself ("Zuzalu City Japan | Zuzalu City Japan") - rewrite as "Zuzalu City Japan - Coliving + Popup City Hub | ZuCity" to differentiate. (2) Add 2-3 more H2s above "Available Listings" that frame what Zucity IS for first-time visitors who land here from external links. Currently the page assumes you know.
3. Neighborhood page (/en/about/zucity/neighborhood)
Verdict: Strong page. Schema includes AboutPage (correct type). "Brooklyn 2.0" framing is sticky and differentiated. 8 H2s give the page proper depth. Meta description is positioning-rich ("Why and how we buy properties in Japan. The thesis, the portfolio, and the public goods feedback loop.").
Note on URL spelling: The URL uses American spelling /neighborhood. You mentioned the British spelling /neighbourhood which 404s. No fix needed if American is the deliberate choice; if you want British compatibility, add a 301 redirect from /en/about/zucity/neighbourhood to /en/about/zucity/neighborhood (10 min in your CMS or Next.js redirects config).
4. The Grocery Store - venue (/en/items/3)
Verdict: The strongest single page audit-wise. LocalBusiness + EventVenue + GeoCoordinates triple makes this a serious local-SEO target for "Komoro coworking venue" or "Komoro event space" queries. H2s ("Built for gathering, not just renting", "What you can host here", "Common bundle shapes") are conversion-oriented, not just descriptive.
Fix: Nothing critical. Optional: add Event schema for upcoming hosted events with future dates to capture "events near Komoro" / event-time queries.
5. ZuCity Japan Daily Access - ticket (/en/items/1)
Verdict: Strong page, schema-rich. The pricing drop $80 to $50 is a real conversion-friendly move. The FAQPage + HowTo schema is the headline win: both are Google rich-result eligible. When someone searches "how to visit ZuCity" or "ZuCity Japan FAQ", the page is structured to answer in expandable rich results.
Fix: Nothing critical. Optional: surface the FAQ content above the fold or in a prominent collapsible block so JA users on mobile see it quickly (rich-result CTR is good but only fires if Google parses the structure cleanly).
Partner-marketplace wedge (NEW since 2026-05-28)
The redesign added 103 new item URLs, almost all partner-property listings. The 18183939 ID series and the 8888 series are Kiba's ETL ingesting ADDress, Maki House, Route Inn Court, Horakuan Zen Buddhist Retreat Center, Finnish Log Cabin, Coliving Studio Kamikawa, Coliving Kurogi Farmhouse, and ~12 more partner properties into the Zucity catalog. This is a structural wedge, not a content addition - the strategic implication matters more than the per-listing audit.
What this shapes Zucity into
- Zucity moves from "single coliving community in Komoro" to "multi-property coliving + accommodation marketplace across rural Japan".
- Same brand wraps owned properties (the original 20 items) AND curated partner properties (the 103 new ones).
- The /en/all and /ja/all aggregated listing pages exist (not in the original 5-page review scope but worth flagging) - these are the catalog discovery surfaces.
- Per-location pages (/en/nagano, /komoro, /hokkaido, /kyuushuu, /ryukyu, /chiangmai, /tokyo) become the geo-funnel mid layer.
SEO opportunity sized to this shape
- Long-tail location + property queries - each partner property is a long-tail "{property name} {city} coliving" target. 103 new pages = 103 new content-eligible URLs.
- Per-location landing pages are now legitimate hub pages and should target "{prefecture} coliving" / "{prefecture} digital nomad" / "{prefecture} pop-up community" queries.
- Aggregator schema - /en/all could ship
CollectionPage+ItemListJSON-LD to help Google understand the multi-property structure (worth checking if it does today).
SEO debt this shape introduces
Per Bug 4 above - 179 of 246 item URLs (the partner imports) have 1-5 word JSON-LD descriptions. The ETL pulls room titles but not bodies. This is the highest-leverage fix for the wedge: either revise the ETL or batch-generate descriptions, OR accept the limitation and skip the JSON-LD description field entirely. Right now you have 179 partial-quality pages instead of 179 content-eligible long-tail SEO assets.
Top 10 fixes, ranked by leverage
| # | Fix | Effort | Impact |
|---|---|---|---|
| 1 | Fix $50M schema price on items 12-16 | 10 min | Critical |
| 2 | Decide ETL approach for 179 partner-property descriptions (revise / templated / omit) | 2-4 hr | Highest leverage |
| 3 | Fix homepage canonical (self-reference /en, not /) | 5 min | High |
| 4 | Fix "commmunity" typo in homepage meta description | 30 sec | Easy win |
| 5 | Decide policy for 16 priceless accommodations (price or "by inquiry" CTA) | 30 min | High |
| 6 | Add x-default hreflang to on-page head (currently sitemap-only) | 10 min | Medium |
| 7 | Rewrite duplicate title on /en/zucity ("Zuzalu City Japan | Zuzalu City Japan") | 5 min | Medium |
| 8 | Add 2-3 framing H2s above "Available Listings" on /en/zucity | 30 min | Medium |
| 9 | Investigate inline JS payload (213-340KB) to push mobile LCP from AMBER to GREEN | 4-8 hr | Medium |
| 10 | Run full DataForSEO keyword research EN + JA (~120 terms, ~$3-5 spend) | 4 hr | Strategic |
Connection map
- ai-visibility.html - the 4-platform AI citation audit (Claude / Perplexity / ChatGPT / Google AI Mode). Fixes in this report improve those numbers.
- items-content.html - yesterday's catalog audit. Bugs 1, 4, 5 above are confirmed from that audit.
- backlinks-strategy.html - the earned-mention playbook. The new partner-property wedge gives you 103 new linkable surfaces.
- outreach-plan.html - the 12-week DIY outreach calendar.
- cro.html - 4 funnel teardowns. Item 1 daily access pricing drop $80 to $50 is worth re-scoping the CRO take.
- growth-plan.html - 90-day 3-track plan. Track 1 (Wedge launch) now has the partner-marketplace as an active wedge to consider.
Audit source: full crawl of https://zucity.org/sitemap.xml (292 URLs, 146 EN + 146 JA), executed 2026-05-30 at 19:36. JSON-LD extracted from Next.js stream chunks. TTFB measured via curl, 2-run average. Page-speed estimates are heuristic (PSI v5 rate-limited unauthenticated; verifiable Lighthouse runs available in follow-up). Deep keyword research deferred to follow-up to stay under cost cap this round. All artifacts archived at agency-deliverables/kiba-zucity/lead-audit/redesign-2026-05-30/.