Specoria Commerce Readiness Specification 1.0

SC-ACCESS-01 Search and user agents allowed (robots.txt)

Level

MUST

Weight

8 of 100

Applies to

Online stores · Hotels and lodging · Service businesses

Test check

bots_search

Requirement (MUST): Search and user agents are explicitly allowed. You can still block training bots (GPTBot, ClaudeBot, Google-Extended); that doesn’t cut visibility.

How it’s tested: We read robots.txt and test the root and the product page’s path for search bots (OAI-SearchBot, Claude-SearchBot, PerplexityBot, Googlebot, Bingbot, Applebot) and user agents (ChatGPT-User, Claude-User, Perplexity-User, Google-Agent). Blocking any of them fails the check; blocking OAI-SearchBot or Googlebot is a critical blocker. No robots.txt passes; an unreadable one (server error, timeout) is not verifiable. Training bots (GPTBot, ClaudeBot, Google-Extended, CCBot) and other AI bots (Applebot-Extended, Meta-ExternalAgent, Amazonbot, MistralAI-User, Bytespider) don’t count and are shown as information rows; so are agent-specific groups that override the general (*) rules and any Content-Signal declaration.

Based on: RFC 9309: Robots Exclusion Protocol ↗ · OpenAI: crawlers and user agents ↗

Check page, fix code and self-check →

SC-ACCESS-02 Is bot protection open to agents?

Level

MUST

Weight

8 of 100

Applies to

Online stores · Hotels and lodging · Service businesses

Test check

waf_access

Requirement (MUST): Bot protection stops only malicious traffic; verified search and user agents get the normal page (HTTP 200). Risk-based checks and rate limits (HTTP 429 + Retry-After) replace a CAPTCHA at every step.

How it’s tested: We request the homepage and the product page with ordinary browser headers. A hard refusal (e.g. HTTP 403) fails the check and is a critical blocker. A challenge page or CAPTCHA is a “possible block”: a partial pass, not a critical blocker, since we can’t see from outside what verified agents get. A rate limit (HTTP 429) isn’t counted as a block: we retry after the Retry-After wait; if the page opens it passes, if it’s still limited the check is not verifiable and doesn’t count. If the homepage is blocked from Cloudflare’s network but opens from a second network, it’s a partial pass. If only the one request that identifies itself as SpecoriaBot is refused, that’s also a “possible block” (partial pass): we can’t send requests from verified bot IPs.

Based on: OpenAI: crawlers and user agents ↗

Check page, fix code and self-check →

SC-ACCESS-03 Product name and price readable without JavaScript

Level

MUST

Weight

5 of 100

Applies to

Online stores · Hotels and lodging · Service businesses

Test check

no_js

Requirement (MUST): Product name, price, currency and stock are in the initial HTML (server-side rendering or static generation).

On hotel and service sites (measured on the homepage): The business name, headings and main content are in the initial HTML (server-side rendering or static generation).

How it’s tested: We read the product page’s initial HTML, without running JavaScript: are the product name (structured data, og:title or h1) and the price in it? If either is missing the check fails and is a critical blocker. On hotel and service sites we look for the business name and at least 200 characters of readable text on the homepage.

Based on: Google: JavaScript SEO basics ↗

Check page, fix code and self-check →

SC-ACCESS-04 Sitemap

Level

SHOULD

Weight

2 of 100

Applies to

Online stores · Hotels and lodging · Service businesses

Test check

sitemap

Requirement (SHOULD): An up-to-date sitemap lists your product pages and is referenced from robots.txt.

On hotel and service sites (measured on the homepage): An up-to-date sitemap lists your important pages and is referenced from robots.txt.

How it’s tested: We look for a “Sitemap:” line in robots.txt or for /sitemap.xml. Found passes, neither fails; if the file can’t be read, it’s not verifiable.

Based on: sitemaps.org protocol ↗

Check page, fix code and self-check →

SC-ACCESS-05 Can the product page be indexed?

Level

SHOULD

Weight

2 of 100

Applies to

Online stores · Hotels and lodging · Service businesses

Test check

indexable

Requirement (SHOULD): Product pages are indexable and their canonical points to themselves.

On hotel and service sites (measured on the homepage): The homepage and important pages are indexable and each canonical points to the page itself.

How it’s tested: On the product page (or the homepage if there’s none) we look for “noindex” in meta robots and the X-Robots-Tag header; if present the check fails. A canonical URL pointing to another domain is a partial pass.

Based on: Google: block indexing with noindex ↗

Check page, fix code and self-check →

SC-DATA-01 Product structured data (schema.org)

Level

MUST

Weight

7 of 100

Applies to

Online stores

Test check

product_schema

Requirement (MUST): Every product page carries Product data as JSON-LD; products with variants use ProductGroup + hasVariant.

How it’s tested: We look for JSON-LD Product (or ProductGroup) on the product page. Only microdata or Open Graph product tags is a partial pass; none fails and is a critical blocker.

Based on: schema.org/Product ↗ · Google: merchant listing structured data ↗

Check page, fix code and self-check →

SC-DATA-02 Price, currency, availability and URL

Level

SHOULD

Weight

6 of 100

Applies to

Online stores

Test check

offer_complete

Requirement (SHOULD): The offer carries price, an ISO currency code, availability and the product URL together.

How it’s tested: We count four fields in the product’s offer: price, a valid ISO 4217 currency, availability and the offer URL. All four pass, none fails; anything in between earns points in proportion.

Based on: schema.org/Offer ↗ · Google: merchant listing structured data ↗

Check page, fix code and self-check →

SC-DATA-03 Product identity (GTIN/MPN, brand, SKU)

Level

SHOULD

Weight

5 of 100

Applies to

Online stores

Test check

product_identity

Requirement (SHOULD): Brand and a valid GTIN (barcode) or MPN are defined; the SKU is there too.

How it’s tested: We read product identity from structured data: a valid GTIN (correct check digit) or an MPN, the brand and the SKU. An identifier plus the brand passes; none fails; partial credit weighs the identifier 50%, the brand 35% and the SKU 15%. The result also states identity confidence (no effect on score): a valid GTIN is “strong”, an MPN with the brand and no GTIN is “medium”, the product name alone is “weak”.

Based on: GS1: GTIN ↗ · schema.org/gtin ↗

Check page, fix code and self-check →

SC-DATA-04 Images and description

Level

SHOULD

Weight

2 of 100

Applies to

Online stores

Test check

product_media

Requirement (SHOULD): JSON-LD carries a stable https image URL and an original description; og:image is set as well.

How it’s tested: We read the product image (structured data or og:image) and the description in the product’s structured data. A description of at least 20 words or 120 characters is enough; 10-19 words is short; fewer doesn’t count as a description. An image plus an adequate description passes; an image with a short description is a mostly partial pass; only one of the two is a half partial pass; neither fails.

Based on: schema.org/Product ↗

Check page, fix code and self-check →

SC-DATA-05 Reviews and rating

Level

SHOULD

Weight

3 of 100

Applies to

Online stores

Test check

reviews

Requirement (SHOULD): The stars and review count on the page are marked up as AggregateRating too.

How it’s tested: We look for a rating (AggregateRating) in the product’s structured data. A rating above zero with a review or rating count above zero passes; only individual reviews (Review), or a missing or zero count, is a partial pass; nothing fails.

Based on: schema.org/AggregateRating ↗

Check page, fix code and self-check →

SC-DATA-06 Can variants (size, color) be addressed?

Level

SHOULD

Weight

2 of 100

Applies to

Online stores

Test check

variants

Requirement (SHOULD): Every variant opens at its own URL; structured data uses ProductGroup + hasVariant and variesBy.

How it’s tested: Variants described as ProductGroup + hasVariant in structured data pass; if there are at least two colour variants, each colour needs its own distinct image, otherwise it’s a partial pass (size-only variants aren’t checked for images). If the page has a size/colour selector but no such data: options with their own URLs are a partial pass, options without fail. Products without a selector are not applicable.

Based on: schema.org/ProductGroup ↗ · Google: product variants ↗

Check page, fix code and self-check →

SC-POLICY-01 Machine-readable return policy

Level

SHOULD

Weight

5 of 100

Applies to

Online stores

Test check

returns_machine

Requirement (SHOULD): The return policy is defined once at organization level (OnlineStore → hasMerchantReturnPolicy) or on the product offer, with the same values as your returns page.

How it’s tested: We look for a machine-readable return policy (MerchantReturnPolicy) at product, offer or Organization level, resolving @id references. We check three fields: the window type (returnPolicyCategory), a whole number of days for a finite window (merchantReturnDays; “30 days” or 14.5 don’t count) and the country (applicableCountry). All complete passes; a policy with missing fields is a partial pass (one missing 0.75, two 0.6, all three 0.5 points); no policy fails.

Based on: schema.org/MerchantReturnPolicy ↗ · Google: merchant listing structured data ↗

Check page, fix code and self-check →

SC-POLICY-02 Returns page and window

Level

SHOULD

Weight

4 of 100

Applies to

Online stores

Test check

returns_human

Requirement (SHOULD): The homepage links to an HTML returns page that states the window, fees and method clearly.

How it’s tested: We find the returns page from links on the homepage and product page, open it and look for the return window (days). Days found passes; a page without days, or a PDF-only policy, is a partial pass; no page fails.

Check page, fix code and self-check →

SC-POLICY-03 Machine-readable shipping information

Level

SHOULD

Weight

4 of 100

Applies to

Online stores

Test check

shipping_machine

Requirement (SHOULD): Shipping rate, handling and transit times are defined with OfferShippingDetails.

How it’s tested: We look for machine-readable shipping details (OfferShippingDetails or ShippingService) in the offer or at Organization level and count four fields: shipping cost (shippingRate), delivery region (shippingDestination), handling time (handlingTime) and transit time (transitTime); the times may sit under deliveryTime or shippingConditions. All four pass; a definition with missing fields is a partial pass (one missing 0.75, two 0.6, more 0.5 points); no definition fails.

Based on: schema.org/OfferShippingDetails ↗ · Google: merchant listing structured data ↗

Check page, fix code and self-check →

SC-POLICY-04 Shipping cost and time on the page

Level

SHOULD

Weight

3 of 100

Applies to

Online stores

Test check

shipping_human

Requirement (SHOULD): The product page shows shipping cost, the free-shipping threshold and delivery time before the cart.

How it’s tested: We look for a free-shipping threshold or a delivery time in the product page, the shipping page and the homepage text. Either found passes; a vague mention of shipping is a partial pass; nothing fails.

Check page, fix code and self-check →

SC-POLICY-05 Business identity

Level

SHOULD

Weight

2 of 100

Applies to

Online stores

Test check

org_identity

Requirement (SHOULD): The homepage carries OnlineStore data with name, address, contact details and social profiles.

How it’s tested: We look for the business (Organization) in the structured data of the pages we read: contact details and social profile links (sameAs). Both pass, one missing is a partial pass, no business data fails.

Based on: schema.org/Organization ↗

Check page, fix code and self-check →

SC-POLICY-06 Legal pages (distance selling, Türkiye)

Level

SHOULD

Weight

2 of 100

Applies to

Online stores

Test check

legal_pages

Requirement (SHOULD): The footer links to the distance sales contract, the pre-information form and the privacy notice.

How it’s tested: Measured only for the Turkish market: we look for a distance sales contract, a pre-information form and a privacy notice among the homepage and product page links. All three pass, none fails, anything in between is scored in proportion. Not applicable in other markets.

Check page, fix code and self-check →

SC-CONSISTENCY-01 Price consistency

Level

MUST

Weight

6 of 100

Applies to

Online stores

Test check

price_match

Requirement (MUST): Visible price = structured-data price = feed price (taxes included, same currency).

How it’s tested: We compare the structured-data price with the product price meta tag and the visible page text. A meta tag with a different price fails the check and is a critical blocker; a price that isn’t visible on the page is a partial pass.

Based on: schema.org/Offer ↗

Check page, fix code and self-check →

SC-CONSISTENCY-02 Stock consistency

Level

SHOULD

Weight

3 of 100

Applies to

Online stores

Test check

stock_match

Requirement (SHOULD): Availability is real-time and machine-readable (InStock, OutOfStock, PreOrder).

How it’s tested: We compare the structured-data availability with the page: data saying “in stock” while the page says “sold out” with no add-to-cart fails; data saying “out of stock” while the page is buyable is a partial pass.

Based on: schema.org/ItemAvailability ↗

Check page, fix code and self-check →

SC-CONSISTENCY-03 Currency and language

Level

SHOULD

Weight

2 of 100

Applies to

Online stores · Hotels and lodging · Service businesses

Test check

market_match

Requirement (SHOULD): priceCurrency is an ISO 4217 code (e.g. USD) and <html lang> matches the page language.

On hotel and service sites (measured on the homepage): <html lang> matches the page language; where prices are shown, the currency is an ISO 4217 code (e.g. USD).

How it’s tested: We compare the price currency with the domain’s market (e.g. .com.tr → TRY) and the page language (<html lang>) with the market’s language. A mismatched currency fails; a missing or different language tag is a partial pass.

Check page, fix code and self-check →

SC-CONSISTENCY-04 Return window consistency

Level

SHOULD

Weight

2 of 100

Applies to

Online stores

Test check

policy_match

Requirement (SHOULD): The return window in structured data equals the one on the returns page.

How it’s tested: We compare the return window in structured data with the one on the returns page. Equal passes, different fails; if either is missing there’s nothing to compare and it isn’t counted.

Check page, fix code and self-check →

SC-CONSISTENCY-05 Taxes-included wording

Level

SHOULD

Weight

2 of 100

Applies to

Online stores

Test check

price_transparency

Requirement (SHOULD): The price states that taxes are included, and shipping cost is visible before the cart.

How it’s tested: For Türkiye, EU countries, the UK, Switzerland, Australia and New Zealand we look for a “VAT included” style phrase in the product page and homepage text. Present passes, absent fails; other markets are not applicable.

Check page, fix code and self-check →

SC-CART-02 Add-to-cart button in the initial HTML

Level

SHOULD

Weight

5 of 100

Applies to

Online stores

Test check

add_to_cart

Requirement (SHOULD): Add to cart is a real <button> or form in the initial HTML.

How it’s tested: We look for an add-to-cart signal in the product page’s initial HTML: a cart form, cart attributes or “Add to cart” text. Present passes, absent fails.

Check page, fix code and self-check →

SC-CART-03 Is the cart button accessible?

Level

SHOULD

Weight

3 of 100

Applies to

Online stores

Test check

cart_accessible

Requirement (SHOULD): The button is a <button> or form submit with visible text or an aria-label.

How it’s tested: If add-to-cart was found, we check whether it’s a real button or form and whether it has a readable name (text or aria-label). Both pass, one is a partial pass, neither fails.

Based on: WAI-ARIA: button pattern ↗

Check page, fix code and self-check →

SC-CART-01 Site search that works by URL

Level

SHOULD

Weight

1 of 100

Applies to

Online stores

Test check

site_search

Requirement (SHOULD): Search submits a GET form to a URL parameter; WebSite data declares a SearchAction.

How it’s tested: We look for search that works through a URL parameter on the homepage: a SearchAction in structured data or a search form sent with GET (q, s, search…). A script-only search box is a partial pass; no search fails.

Based on: schema.org/SearchAction ↗

Check page, fix code and self-check →

SC-CHECKOUT-01 Buying without an account

Level

SHOULD

Weight

4 of 100

Applies to

Online stores

Test check

guest_checkout

Requirement (SHOULD): Guest checkout is on; few steps, no pop-ups or forced newsletter sign-ups.

How it’s tested: Guest checkout can’t be seen from outside without a browser; in the free test it’s always not verifiable and doesn’t count. The deep audit report measures it with a real browser.

Check page, fix code and self-check →

SC-CHECKOUT-02 Order tracking

Level

SHOULD

Weight

2 of 100

Applies to

Online stores

Test check

order_tracking

Requirement (SHOULD): A guest order tracking page (order number + email) and a carrier tracking link are available.

How it’s tested: We look for an order-tracking link that works without signing in (e.g. “Track order”) among the homepage and product page links. Present passes, absent fails.

Check page, fix code and self-check →

SC-HOTEL-01 Hotel structured data (Hotel / LodgingBusiness)

Level

SHOULD

Weight

18 of 100 (with the common checks)

Applies to

Hotels and lodging

Test check

lodging_schema

Requirement (SHOULD): The homepage carries one Hotel (or Resort, BedAndBreakfast…) node with name, address, geo coordinates, phone, star rating and check-in/check-out times.

How it’s tested: We look for Hotel / LodgingBusiness structured data on the homepage and count seven fields: name, address, location, phone, star rating, check-in and check-out time. All pass, no data fails, anything in between is scored in proportion.

Based on: schema.org/Hotel ↗ · schema.org/LodgingBusiness ↗

Check page, fix code and self-check →

SC-HOTEL-02 Amenities in structured data

Level

SHOULD

Weight

8 of 100 (with the common checks)

Applies to

Hotels and lodging

Test check

lodging_amenities

Requirement (SHOULD): Every amenity a guest might filter on is listed as a LocationFeatureSpecification (name + value: true).

How it’s tested: We look for amenities (amenityFeature) in the hotel or room data. Present passes; amenities mentioned only in text (pool, breakfast, parking…) are a partial pass; nothing fails.

Based on: schema.org/LocationFeatureSpecification ↗

Check page, fix code and self-check →

SC-HOTEL-03 Rooms and prices readable

Level

SHOULD

Weight

15 of 100 (with the common checks)

Applies to

Hotels and lodging

Test check

room_offers

Requirement (SHOULD): Each room type is a HotelRoom with occupancy and bed details, offered through an Offer with a “from” price and currency.

How it’s tested: We look for room types (HotelRoom, Suite…) and priced offers in the homepage structured data. Both pass, one is a partial pass, neither fails.

Based on: schema.org/HotelRoom ↗ · schema.org/Offer ↗

Check page, fix code and self-check →

SC-HOTEL-04 Cancellation policy discoverable

Level

SHOULD

Weight

12 of 100 (with the common checks)

Applies to

Hotels and lodging

Test check

cancellation_policy

Requirement (SHOULD): A plain-text cancellation policy page (deadline, fees, no-show) linked from every page.

How it’s tested: We look for a link to the cancellation or booking terms on the homepage; found passes. Terms mentioned only in text are a partial pass, nothing fails. The linked page isn’t opened.

Check page, fix code and self-check →

SC-HOTEL-05 Booking entry point reachable

Level

SHOULD

Weight

20 of 100 (with the common checks)

Applies to

Hotels and lodging

Test check

booking_entry

Requirement (SHOULD): A plain <a href> to the booking engine (with dates as URL parameters if possible) or a GET form with check-in/check-out fields.

How it’s tested: We look for a real form with check-in/check-out dates, or a link to booking, on the homepage; found passes. A booking engine that only shows up in scripts is a partial pass; neither fails.

Check page, fix code and self-check →

SC-SERVICE-01 Business structured data (Organization / ProfessionalService)

Level

SHOULD

Weight

18 of 100 (with the common checks)

Applies to

Service businesses

Test check

service_org

Requirement (SHOULD): One ProfessionalService (or Organization / LocalBusiness) node with name, contact details, address and the area served.

How it’s tested: We look for business structured data (Organization, LocalBusiness, ProfessionalService…) on the homepage and count three fields: name, contact (phone or email) and area served (areaServed). All pass, no data fails, anything in between is scored in proportion.

Based on: schema.org/LocalBusiness ↗ · schema.org/ProfessionalService ↗

Check page, fix code and self-check →

SC-SERVICE-02 Services described

Level

SHOULD

Weight

15 of 100 (with the common checks)

Applies to

Service businesses

Test check

service_pages

Requirement (SHOULD): One page per service, linked from the homepage, each with Service data pointing to your organization.

How it’s tested: We look for Service definitions in structured data or links to service pages on the homepage (“Our services”, /services…). Either passes, neither fails.

Based on: schema.org/Service ↗

Check page, fix code and self-check →

SC-SERVICE-03 Pricing or “how it works” discoverable

Level

SHOULD

Weight

10 of 100 (with the common checks)

Applies to

Service businesses

Test check

pricing_info

Requirement (SHOULD): A pricing or packages page (starting prices are enough) and a short “how it works” section, both linked from the homepage.

How it’s tested: We look for pricing or “how it works” information: a link to a pricing page, a price in structured data or an amount in the homepage text. Any of them passes, none fails.

Check page, fix code and self-check →

SC-SERVICE-04 Contact details readable

Level

SHOULD

Weight

12 of 100 (with the common checks)

Applies to

Service businesses

Test check

contact_details

Requirement (SHOULD): Email and phone are plain text with mailto:/tel: links in the header or footer of every page.

How it’s tested: We look for an email address and a phone number on the homepage (link, text or structured data). Both pass, one is a partial pass, neither fails.

Based on: schema.org/ContactPoint ↗

Check page, fix code and self-check →

SC-SERVICE-05 Contact or quote form within one click

Level

SHOULD

Weight

18 of 100 (with the common checks)

Applies to

Service businesses

Test check

contact_form

Requirement (SHOULD): A plain HTML form (name, email, message) reachable in one click from the homepage, with clearly labelled fields.

How it’s tested: We look for a real contact or quote form (with a text area or an email/phone field) or a link to a contact/quote page on the homepage; found passes. Only an email link is a partial pass; nothing fails. Nothing is ever typed into the form.

Check page, fix code and self-check →