AI 검색 준비 상태은(는) 무엇을 하나요?

세 가지 조치. 이는 non-commodity-content가 다루는 콘텐츠 품질이 아닙니다. 이는 사이트가 고객을 대신하는 기계에 의해 발견되고, 견적이 제공되며, 거래될 수 있는지 여부입니다.

사이트가 모든 콘텐츠 규칙을 통과하더라도, 숫자를 게시하지 않았거나 기계가 읽을 수 있는 예약 엔드포인트를 노출하지 않았다면 에이전트에게 보이지 않을 수 있습니다.

조치 1: 가격 범위 공개

규칙. 모든 상업 사이트는 서비스 비용이 얼마인지 게시합니다. 가격표가 아닙니다. 두 끝과 그 사이의 숫자를 결정하는 요소가 포함된 범위입니다.

사람들은 AI에게 물건 가격이 얼마인지 끊임없이 묻습니다. 견적을 제시할 내용이 없는 AI는 가격을 게시한 경쟁사로 사용자를 보냅니다. "가격은 문의"는 기계에게 막다른 길이며, 점점 더 사람에게도 마찬가지입니다.

최소한 게시해야 할 사항:

실제 숫자로 표시된 최저 가격과 최고 가격
가격 변동 요인: 작업 비용을 결정하는 두세 가지 변수
숫자 옆에 표시된 범위 측정 날짜
모든 고정 수수료 전액: 배송비, 설치비, 보증금, 청소비, 최소 금액, 위약금
정확한 견적을 위한 실시간 출처 링크

반론과 답변. 운영자는 가격이 변동하고 오래된 수치에 구속될 것을 우려하여 저항합니다. 이 반론은 단일 고정 가격을 가격으로 제시하는 것에 대한 것입니다. 범위에 대한 반론이 아닙니다. 측정 날짜와 변동 요인이 명시된 범위는 침묵보다 더 정확하며, 운영자가 독특하게 제시할 수 있는 것입니다.

이를 해결하는 규칙. 단순한 요금을 게시하지 마십시오. 다음과 같이 게시하십시오:

2026년 9월 18일 기준, 차량군 전체의 1박 요금은 $106에서 $175 사이입니다. 어떤 캠핑카와 어떤 날짜인지에 따라 최종 요금이 결정됩니다. 정확한 요금을 확인하려면 날짜를 확인하세요.

다음과 같이 하지 마십시오:

캠핑카 1박 $106부터.

가격을 두 번 입력하지 마십시오. 빌드 시점에 비즈니스가 이미 유지 관리하는 소스(예약 플랫폼 피드, POS, 게시된 요금표)에서 가격을 읽어오십시오. 페이지에 입력된 가격은 한 달 내에 체크아웃 가격과 일치하지 않게 됩니다. 운영자 자체 페이지에서 숫자를 파싱하면 둘이 어긋날 수 없습니다.

요금을 정말로 게시할 수 없는 경우 (작업별로 견적되거나 제3자가 설정한 경우), 페이지는 고정된 모든 항목(수수료표, 최소 금액, 보증금, 예약 변경 위약금)을 계속 독자에게 제공해야 합니다. 그런 다음 요금 자체는 견적 시 결정되며 어디서 받을 수 있는지 명확히 밝히십시오. "X를 게시하지 않습니다. 이유는 다음과 같고, 여기서 받을 수 있으며, 변하지 않는 모든 것은 다음과 같습니다"라고 말하는 페이지는 아무 말도 하지 않는 페이지보다 낫습니다.

모든 가격 페이지 사전 게시 확인 사항:

범위의 양 끝이 "부터"가 아닌 실제 숫자입니다.
가격을 변동시키는 요인이 명시되어 있습니다.
측정 날짜가 숫자 옆에 있습니다.
모든 고정 수수료가 전액 게시되었습니다.
숫자가 빌드 시점에 소스에서 읽혀지고 입력되지 않았습니다.
구조화된 데이터가 본문과 동일한 숫자를 전달합니다 (조치 2 참조).
가격을 책정할 수 없는 경우 페이지에 그렇게 명시하고 견적 위치를 알려줍니다.

조치 2: 에이전트 준비된 스케줄링

규칙. 고객의 에이전트가 달력과 거래하는 방법을 볼 수 없으면 비즈니스는 에이전트에게 보이지 않습니다. 에이전트 방식 예약은 이미 활성화되어 있습니다. 어시스턴트가 테이블, 서비스 콜, 렌탈을 예약할 것입니다. 구조화된 데이터를 먼저 찾고 DOM을 다음으로 찾습니다.

세 가지 계층, 모두 필요합니다.

1. 구조화된 데이터의 오퍼. 예약 가능한 모든 항목은 실제 가격 또는 priceSpecification 범위, 통화, 재고 상태, 측정 날짜와 일치하는 priceValidUntil이 포함된 Offer를 전달합니다. 비즈니스의 priceRange만으로는 충분하지 않습니다. 기계는 예약을 요청받은 항목의 오퍼를 원합니다.

"offers": {
  "@type": "Offer",
  "priceCurrency": "USD",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "priceCurrency": "USD",
    "minPrice": 106,
    "maxPrice": 175,
    "unitCode": "DAY",
    "referenceQuantity": { "@type": "QuantitativeValue", "value": 1, "unitCode": "DAY" }
  },
  "availability": "https://schema.org/InStock",
  "priceValidUntil": "2026-12-31",
  "url": "https://example.com/book"
}

2. 액션. 엔터티는 예약 엔드포인트, HTTP 대상 및 필요한 입력을 명명하는 potentialAction을 전달합니다. 이것은 거의 아무도 게시하지 않는 부분이며 에이전트가 실제로 필요로 하는 부분입니다.

"potentialAction": {
  "@type": "ReserveAction",
  "name": "이 캠핑카 예약",
  "target": {
    "@type": "EntryPoint",
    "urlTemplate": "https://example.com/book?rental_id={rental_id}&from={checkin}&to={checkout}",
    "actionPlatform": [
      "https://schema.org/DesktopWebPlatform",
      "https://schema.org/MobileWebPlatform"
    ],
    "httpMethod": "GET"
  },
  "result": { "@type": "Reservation", "name": "캠핑카 렌탈 예약" },
  "object": { "@type": "Product", "name": "2023 Jayco Jay Flight" }
}

동사와 일치하는 액션 유형을 선택하십시오: 예약 또는 예약의 경우 ReserveAction, 약속의 경우 ScheduleAction, 구매의 경우 OrderAction, 이벤트의 경우 RsvpAction.

3. 데이터로 명시된 제약 조건, 산문이 아닌. 비즈니스가 이행할 수 없는 숙박을 예약하는 에이전트는 모든 사람의 시간을 낭비하게 합니다. 예약을 실패하게 만드는 규칙을 게시하십시오:

최소 및 최대 기간
리드 타임 및 마감 시간 (availabilityStarts, advanceBookingRequirement)
자격 (최소 연령, 면허, 보증금)
서비스 지역 (areaServed), 그리고 각 지역에 도달하는 비용
도착 시간이 다른 사람에 의해 제한되는 경우, 영업 또는 배송 시간 창

각 항목을 속성이 존재하는 스키마에, 존재하지 않는 페이지의 일반 문장에 넣으십시오. 항상 둘 다: 에이전트는 하나를 읽고, 사람은 다른 하나를 읽으며, 둘은 일치해야 합니다.

에이전트가 읽을 수 있는 렌더링. 중요한 콘텐츠는 서버에서 렌더링되고, 시맨틱 HTML, 실제 제목, 대체 텍스트, <table>로 테이블을 사용합니다. 에이전트는 DOM과 접근성 트리를 읽습니다. 클라이언트 측 가져오기 이후에만 나타나는 콘텐츠는 에이전트가 보지 못한 콘텐츠입니다.

기능을 가장하지 마십시오. 실제로 예약을 수락하는 엔드포인트에 대해서만 ReserveAction을 게시하십시오. 문의 양식을 가리키는 액션은 에이전트가 행동할 거짓말이며, 고객은 최악의 순간에 알게 됩니다. 예약이 실제로 전화로 이루어지는 경우, 스키마에 전화번호를 게시하고 예약 액션은 게시하지 마십시오.

프로토콜 계층 및 구축할 계층

세 가지 계층이 존재합니다. 대안이 아니라 쌓여 있으며, 낮은 계층이 오늘날 읽히고 상위 계층은 아직 대부분 읽히지 않기 때문에 순서가 중요합니다.

계층 1: 구조화된 데이터 (항상 먼저 구축). 위와 같이 Offer와 potentialAction입니다. 오늘날의 어시스턴트가 비즈니스에 대한 질문에 답하고 행동을 위해 링크를 따를 때 실제로 소비하는 것입니다. JSON-LD 페이지 한 개면 충분하며 즉시 작동합니다.

계층 2: 기계가 읽을 수 있는 피드. 카탈로그(대여 또는 판매 품목, 각 품목의 가격, 제약 조건, 예약 URL, 측정 날짜)를 보유한 하나의 안정적인 JSON URL입니다. 프로토콜 약정이 없고, 방어할 엔드포인트가 없으며, 모든 에이전트, 크롤러 또는 자매 사이트가 읽을 수 있습니다. 저렴하며, 이후에 계층 3을 하루 아침 작업으로 만드는 요소입니다.

계층 3: A2A (Agent2Agent). 에이전트 간 작업 위임을 위한 개방형 프로토콜: 잘 알려진 URL의 에이전트 카드는 에이전트의 신원, 기술 및 인증을 설명하고, 작업을 수락하고 결과를 반환하는 JSON-RPC over HTTPS를 사용하는 엔드포인트입니다. 고객의 어시스턴트가 페이지를 읽는 대신 질문하고 답변을 받을 수 있어야 할 때 올바른 답변입니다.

현재 위치에 대해 솔직하십시오. 2026년 말 현재, 소비자 어시스턴트가 에이전트 카드를 정기적으로 크롤링하는 레지스트리는 없습니다. 따라서 카드를 게시하는 것은 발견 가능성이 도래할 것이라는 베팅이며, 이번 분기 예약의 원천이 아닙니다. 비즈니스에 정적 피드가 답할 수 없는 에이전트가 실제로 물어봐야 할 것이 있을 때, 일반적으로 실시간 가용성일 때 구축하십시오.

정직 규칙이 여기서 가장 엄격하게 적용됩니다. 에이전트 카드는 기술을 선언하고, 다른 에이전트가 이를 호출할 것입니다. 엔드포인트가 실제로 수행하는 것만 선언하십시오. 대부분의 소규모 운영자는 결제, 보험 및 렌탈 계약이 타사 플랫폼 내에 있기 때문에 에이전트 간 예약을 전혀 완료할 수 없습니다. 괜찮습니다. 카드는 다음과 같이 말해야 합니다:

{
  "name": "Example Rentals 예약 어시스턴트",
  "description": "하나의 차량군에 대한 가용성 및 가격 질문에 답변합니다. 결제를 받을 수 없습니다.",
  "skills": [
    { "id": "check-availability", "description": "두 날짜 사이에 사용 가능한 유닛" },
    { "id": "quote-stay", "description": "유닛 및 날짜에 대한 총액, 마을별 배송비 포함" }
  ],
  "capabilities": { "streaming": false, "pushNotifications": false }
}

리디렉션으로 끝나는 book-stay 기술을 주장하는 카드는 반대편에 기계가 아닌 사람이 있는 연락처 양식을 가리키는 ReserveAction과 동일한 실패입니다.

결제. 에이전트 결제 레일(A2A 확장으로서의 AP2 및 경쟁 에이전트 상거래 사양)은 빠르게 발전하고 있으며 대부분의 예약 플랫폼에서 지원되지 않습니다. 이를 중심으로 체크아웃을 설계하지 마십시오. 플랫폼 자체 체크아웃으로 넘기고 카드에 명시하십시오.

모든 예약 가능 페이지의 사전 게시 확인 사항:

가격 또는 가격 범위, 통화, 재고 상태, priceValidUntil이 포함된 Offer
에이전트가 호출할 수 있는 실제 EntryPoint가 포함된 potentialAction
액션의 URL 템플릿 매개변수가 예약 시스템이 실제로 사용하는 것과 일치합니다.
최소 금액, 리드 타임, 자격 및 서비스 지역이 데이터 및 산문으로 게시되었습니다.
스키마의 모든 수치가 복사본의 수치와 일치합니다.
페이지가 예약 정보를 서버 측에서 렌더링합니다.
존재하지 않는 기능에 대한 액션이 게시되지 않았습니다.

조치 3: 실제 질문에서 얻은 콘텐츠

규칙. 고객이 실제로 묻는 질문이 콘텐츠입니다. 모든 전화 통화, 모든 이메일, 모든 "예약 전" 질문은 공개적으로, 고객 자신의 말로 답변된 페이지 또는 섹션입니다.

Google의 자체 지침에 따르면 일반적인 조언 콘텐츠("여름을 위한 7가지 팁")는 성과를 내지 못합니다. 성과를 내는 것은 매우 구체적이고 실제적인 것입니다. 오늘 아침 고객이 한 질문은 공개 출처에서 작성하는 경쟁사가 그 질문이 제기되었는지 알지 못하기 때문에 구성상 둘 다 해당됩니다.

운영 습관:

질문을 그대로 캡처합니다. 업계 전문 용어가 아닌 고객의 표현입니다. "지붕 수리하는 동안 우리 집에 배달해 줄 수 있나요?"가 질문입니다. "주거지 배치 물류"는 그렇지 않습니다. 이는 검색어의 명사를 작성하는 것과 같은 규칙입니다.
독자가 질문을 하는 곳에서 답변합니다. 아무도 찾지 않는 블로그 게시물이 아닌, 질문이 발생한 페이지에서 답변합니다.
출처와 함께 답변합니다. 출처가 없는 답변은 의견일 뿐입니다. 인용할 가치가 있는 고정 수수료, 게시된 규칙, 측정된 수치여야 합니다.
답변이 당신이 줄 수 없는 것일 때 말하십시오. 답변이 제3자, 의회, 보험사, 공원에 속하는 경우 그렇게 말하고 누구에게 물어봐야 하는지 이름을 밝히십시오. 그 문장은 자산입니다.
운영자만 아는 것의 목록을 유지하십시오. 모든 프로젝트는 열린 질문 파일을 유지합니다. 그 답변은 아무도 복사할 수 없는 콘텐츠이며, 파일은 인터뷰 의제입니다.

FAQ 블록은 독자를 위한 것이며, FAQPage 마크업을 사용하여 페이지가 무엇을 답변하는지 명확히 밝힙니다. 인용을 얻는 지렛대가 아닙니다. 직접 경험에 기반한 특수성이 우선입니다.

세 가지가 맞물리는 방식

독자는 범위를 인용한 AI 답변에서 도착합니다. 페이지는 수치를 확인하고, 그것을 변동시키는 요인을 명명하며, 실제로 가졌던 질문에 답변합니다. 그런 다음 그들의 에이전트가 예약합니다. 오퍼와 액션이 데이터로 게시되었기 때문입니다.

어느 하나라도 빠지면 체인이 끊어집니다. 훌륭한 콘텐츠와 게시된 가격이 없는 사이트는 인용되지 않습니다. 가격과 액션이 없는 사이트는 거래될 수 없습니다. 둘 다 있지만 일반 콘텐츠만 있는 사이트는 애초에 인용할 가치가 없습니다.

출처

Danny Sullivan 기조연설, Google Search Central Live Toronto, 2026년 4월, 비상품 콘텐츠에 관한 내용.
AI Optimization Guide, Google Search Central, 에이전트 가독성 및 쿼리 팬아웃에 관한 내용.
schema.org Offer, UnitPriceSpecification, ReserveAction, EntryPoint.
A2A (Agent2Agent) 프로토콜, Linux Foundation, 에이전트 카드 및 JSON-RPC 작업 인터페이스용.

AI 검색 준비 상태