FAQPage vs QAPage: Local Business Q&A JSON-LD Type Choice

A customer opens Claude on a Tuesday afternoon and types “does Blue Bottle Shibuya accept PayPay?” The answer that comes back — its wording, its confidence, and whether it points at a specific URL or hedges toward “check the store’s FAQ” — is decided a year earlier, by which schema.org type wrapped that particular question on the business’s site. Same fact, same store, same customer. Two different citation shapes, chosen by a decision the business owner probably never knew they were making.

That decision is FAQPage versus QAPage. Both are schema.org types that describe question-and-answer content. Both are recognized by the four major AI assistants. Both nest a Question and an acceptedAnswer in almost-identical ways. And yet they route citations along completely different paths. This article is the engineer’s view of when to reach for which, why the hybrid is the canonical pattern rather than a compromise, and where the four engines diverge in how they pick up each type.

One methodology note, because the honesty of the rest depends on it. I built out a test matrix of four verticals — restaurants, hair salons, clinics, and retail — with five common Q&A each, implemented in both FAQPage-aggregate and QAPage-per-Q&A form, and probed ChatGPT (browsing), Perplexity, Claude, and Gemini for citation shape. I am reasoning from those probes plus the schema.org type definitions and Google’s structured-data documentation. I cannot see any engine’s ranking code. Read this as documented type semantics plus controlled behavioral probing, not as leaked spec.

The two schemas, side by side

The confusion between these types dissolves once you see them next to each other. FAQPage is a container for many Question nodes; QAPage is a page whose mainEntity is one Question node.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "@id": "https://kitasando-table.example/faq/#faqpage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Do you accept PayPay?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. We accept PayPay, all major credit cards, and Suica / Pasmo at the counter."
      }
    },
    {
      "@type": "Question",
      "name": "Is the terrace reservable?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The four terrace tables are held for walk-ins on weekends and are reservable Monday through Thursday."
      }
    }
  ]
}

And the QAPage counterpart, sitting on its own URL:

{
  "@context": "https://schema.org",
  "@type": "QAPage",
  "@id": "https://kitasando-table.example/faq/paypay/#qapage",
  "mainEntity": {
    "@type": "Question",
    "name": "Do you accept PayPay at Kitasando Table?",
    "text": "Do you accept PayPay at Kitasando Table?",
    "dateCreated": "2026-06-01",
    "answerCount": 1,
    "author": { "@type": "Organization", "@id": "https://kitasando-table.example/#restaurant" },
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Yes. Kitasando Table accepts PayPay, all major credit cards, and Suica / Pasmo at the counter.",
      "dateCreated": "2026-06-01",
      "author": { "@type": "Organization", "@id": "https://kitasando-table.example/#restaurant" },
      "upvoteCount": 12,
      "url": "https://kitasando-table.example/faq/paypay/"
    }
  }
}

Notice what the QAPage adds that the FAQPage does not carry per-question: dateCreated on both Question and Answer, an explicit author reference to the business’s Organization node, an answerCount, a url on the answer itself, and (optionally) an upvoteCount. The QAPage is heavier on a per-question basis, and it also lives on its own URL, which is where the citation shape actually diverges.

Dimension 1 — the type structure

FAQPage is a subtype of WebPage whose mainEntity is an array of Question nodes. Each question has exactly one acceptedAnswer. The container answers many questions at once.

QAPage is a subtype of WebPage whose mainEntity is a single Question node. That question may have one acceptedAnswer plus zero or more suggestedAnswer alternatives. The container answers one question, deeply.

The array-vs-single distinction is not stylistic. It changes the URL cardinality, and URL cardinality is what drives everything else.

Dimension 2 — narrow versus breadth

The most important consequence of the array-vs-single split is what happens when an AI assistant cites you.

An FAQPage citation looks like “From the business’s FAQ page: they accept PayPay.” The URL surface is the FAQ page itself; per-question fragments (URL#question1) exist but are treated as weak identifiers by every engine I probed. The tradeoff is breadth: one URL covers twenty questions, so the assistant can quickly satisfy a wide range of exploratory queries without deciding which specific URL to point at.

A QAPage citation looks like “According to https://kitasando-table.example/faq/paypay/, they accept PayPay, credit cards, and Suica.” The URL is specific to the question, the answer text is quoted, and the citation is narrow in the sense that it commits to a source URL that resolves to exactly the fact being cited. That specificity is what direct-action long-tail queries reward.

A useful mental shorthand: FAQPage optimizes for coverage of many questions with one URL. QAPage optimizes for one question resolved to one URL. The LLMO Framework’s Structure primitive treats these as the two ends of the Q&A layer’s narrow-vs-breadth axis, and the standardization work in progress on the LLMO Schema.org subset explicitly documents them as a paired choice, not competing options.

Dimension 3 — maintenance cost

The array-vs-single split also changes how much you have to touch when Q&A drift happens.

FAQPage keeps twenty questions in one file. Adding one, editing one, or deleting one is a one-file edit. Deployment is a single page’s build cache invalidation. Maintenance cost is low, and it scales sub-linearly: the twenty-first question does not require a twenty-first URL.

QAPage requires one page per question. Twenty questions means twenty URLs, twenty templates, twenty entries in the sitemap, and twenty things to keep updated when a policy changes. Maintenance scales linearly with question count, which is why the sensible ceiling on QAPage-per-Q&A is roughly the top five to eight highest-frequency questions — the ones a business owner would answer on the phone twenty times a week and knows will keep being asked.

Dimension 4 — engine-by-engine pickup shape

The four major assistants agree on the general shape but differ on the UI expression. Here is what I observed across the test matrix:

Engine	FAQPage pickup	QAPage pickup
ChatGPT (browsing)	Question array summarized; per-question fragments treated as weak IDs	Question surfaced as primary source; URL cited as specific source
Perplexity	List-form UI (“Here are some FAQs from the business…”)	acceptedAnswer.text mounted directly on the business card
Claude	Aggregate citation phrase (“From the business’s FAQ page: …”)	Direct citation with URL by slug (“According to /faq/paypay/, …”)
Gemini	Google “People also ask” / accordion rich result across many questions	Individual Q&A entity mapping in the Knowledge Graph, single rich result

The pattern that holds across all four: FAQPage collapses to a summary citation; QAPage produces a direct citation to a specific URL. If you want the assistant to say “According to <your specific URL>,” you need QAPage. If you are fine with “From the FAQ page,” FAQPage does the job at a fraction of the maintenance cost.

The decision hierarchy

For a local business owner facing this choice for the first time, four questions in order resolve almost every case:

1. Is this in the top five to eight questions I get asked? If yes, QAPage per Q&A. If no, FAQPage aggregate.
2. Is the maintenance overhead of a new URL acceptable? If no (small team, low update cadence), FAQPage. If yes, QAPage.
3. Do I want long-tail SEO for the specific query (“does accept PayPay”)? If yes, QAPage with a semantic URL slug (/faq/paypay/, not /faq/1/). If no, FAQPage.
4. Do I want the AI’s citation phrase to point at a specific URL? If yes, QAPage. If “From the business’s FAQ” is fine, FAQPage.

The answers usually cluster. Top-five questions that are worth long-tail SEO are also usually worth the maintenance overhead, and their answers rarely change. Long-tail questions that repeat only occasionally are exactly the ones you do not want twenty extra URLs for.

The hybrid pattern

The canonical implementation is not FAQPage-only or QAPage-only. It is a mix.

Put the top five to eight highest-frequency questions on their own QAPage URLs with semantic slugs:

• /faq/paypay/ — “Do you accept PayPay?”
• /faq/parking/ — “Is parking available?”
• /faq/reservations/ — “Do I need a reservation?”
• /faq/wheelchair/ — “Is the store wheelchair-accessible?”
• /faq/late-night/ — “Are you open past 10 PM?”

Put the long tail — allergy accommodations, Wi-Fi password, pet policy, whether you sell gift cards, and the fifteen other questions that come up once a month — on a single /faq/ FAQPage.

The two do not collide. AI engines route direct-action queries to the QAPage side (narrow, specific URL citation) and exploratory queries to the FAQPage side (breadth, summary citation). You cover both citation shapes at a total maintenance cost of one FAQPage plus five to eight small QAPages.

Common failure modes

The mistakes I keep finding on live sites:

1. Everything on a giant FAQPage with thirty-plus questions. The per-question narrow signal dilutes into noise; assistants summarize the whole page and fail to cite any specific answer.
2. QAPage URLs with numeric slugs (/faq/1/, /faq/2/). The URL loses its own value as an entity signal — semantic slugs like /faq/paypay/ let the URL corroborate the answer text before the parser even reads the JSON-LD.
3. Question.name written as a keyword (“Payment,” “Parking”) instead of a full-sentence question. Assistants do semantic matching against the query; a keyword name matches nothing.
4. suggestedAnswer populated but no acceptedAnswer. The assistant sees N candidate answers with no canonical, hedges the response, and skips direct citation.
5. Attribute-layer and Q&A-layer contradiction. acceptedPaymentMethod on the LocalBusiness node lists PayPay, but the /faq/paypay/ QAPage’s acceptedAnswer says “PayPay not accepted.” Assistants detect the disagreement and refuse to cite either side confidently.
6. acceptedAnswer.text written as a hedge. “Generally we accept PayPay but during busy hours cash is preferred and…” reads as uncertain and gets skipped in favor of a competitor’s clean “Yes, we accept PayPay.”
7. No dateCreated on the QAPage Question / Answer. Assistants use the datestamp to judge freshness; an undated Q&A is treated as possibly stale and may be superseded by a review corpus mention.

Industry snapshots

The pattern holds across verticals; only the specific top-eight changes.

Restaurants — QAPage per Q&A: PayPay accepted, terrace reservable, late-night hours, kids welcome, vegetarian menu, English menu. FAQPage aggregate: allergies, high chairs, Wi-Fi, corkage, dress code.

Hair salons — QAPage per Q&A: walk-ins accepted, male customers welcome, parking, postpartum bookings, bilingual staff, kid-friendly. FAQPage aggregate: styling products used, hair extensions, wedding packages, tipping norms.

Clinics — QAPage per Q&A: insurance accepted, English-speaking staff, same-day appointments, pediatric care, walk-ins, payment plans. FAQPage aggregate: telemedicine, vaccination records, referral requirements, form pre-fill.

Retail — QAPage per Q&A: returns accepted, special orders, fitting rooms, gift wrapping, currency exchange, duty-free. FAQPage aggregate: layaway, membership program, stock check by phone.

The top-eight-plus-long-tail split is what makes the hybrid pattern portable across industries. Only the specific questions shift.

Closing

There is a version of this article I wanted to write that ends “and if you implement all this, AI citations will be perfect forever.” I cannot write that one, because next week Perplexity might change how it treats answerCount on QAPage and my whole matrix rearranges. What I can say is that the structural distinction — many questions per URL versus one question per URL — is old, stable schema.org semantics that predates the current AI wave and will outlast whichever engine ships whichever ranking change next. The four engines’ pickup shapes may drift; the array-vs-single decision won’t.

For today, the takeaway that survives the next spec update: write down your top five to eight most-asked questions, give each one its own QAPage URL with a semantic slug, put everything else on one FAQPage, and check next week which of them ChatGPT actually cites by URL. That single audit will tell you more about how your Q&A layer is being read than any amount of theorizing.

---

Related reading

• QAPage per Q&A — question-answer-store 実装 (JA) — the Japanese-language companion to this piece, focused on QAPage implementation depth (attribute-layer redundancy, per-Q&A narrow citation) rather than the FAQPage-vs-QAPage comparison.
• LocalBusiness vs Place vs Restaurant for AI — the business-entity-layer counterpart to this article’s Q&A-layer type choice. The same “which schema.org subtype” reasoning pattern, one level up.
• Knowledge Graph entity linking — how to wire the QAPage Answer.author field to your LocalBusiness @id, so the Q&A layer feeds back into the entity graph rather than floating orphaned.
• Reading Google Business Profile as JSON-LD — the surface your FAQPage and QAPage nest inside; GBP’s own Q&A field is a third source that has to stay consistent with the two schemas here.
• Reviews and aggregateRating in JSON-LD — the reputation-layer companion. Q&A answers “will they let me in with a dog?”; reviews answer “did other people enjoy it?” — both nest under the same LocalBusiness parent.
• NAP consistency at the entity reconciliation level — the reconciliation pass this article’s Answer.author → Organization @id cross-reference depends on to survive.
• The Three Axes of AI Native MEO — where the FAQPage-vs-QAPage decision sits inside the Structure primitive, alongside Confidence and Provenance.
• LLMO Framework — Structure Layer, which formalizes the Q&A-layer narrow-vs-breadth axis this article walks through, and the Provenance Layer reference for how the resulting citations get routed to first-party vs third-party paths.