Start with the business role, not the markup
A Portuguese business should identify its relevant search market, role, and query category before investing in a special result format. A hotel, a comparison service, a retailer, and a design consultancy need different eligibility checks. A feature visible in a screenshot is not automatically an opportunity for your business.
Google's regional documentation, updated 8 September, lists EEA aggregator and supplier units for hotels, flights, ground transportation, and products. It also describes other experiences with different categories. Treat this as a navigation map to feature-specific requirements, not a blanket statement that every Portuguese website qualifies.
Build a one-page eligibility register
Use a row per business-feature pair. Record where the business operates, where the searcher is, whether the site sells directly or compares suppliers, the relevant query, the official guidance, and the next validation step. Give each row an owner and review date.
| Illustrative business | First feature to investigate | Question before implementation |
|---|---|---|
| Independent hotel | Relevant supplier experience | What participation and data requirements apply? |
| Product comparison service | Relevant aggregator experience | Does the site's actual role meet the definition? |
| Brand consultancy | Ordinary service discovery | Is any specialised feature actually relevant? |
These are illustrative investigation routes, not approvals. In particular, do not assume that ordinary consultancy services become eligible for product or travel units simply because they have prices.
Follow the feature page to its requirements
Once a candidate is plausible, read its specific documentation. Separate business eligibility, content requirements, structured data, feeds, and any participation process. Record which requirements are already met and which need another party, such as a booking platform or product-data owner.
Use four statuses: applicable and ready, applicable with gaps, not applicable, and unresolved. “Unresolved” is useful when the business model does not fit the published examples. It prevents a developer from treating uncertainty as an instruction to build.
Price the work against the likely customer journey
For each applicable feature, identify the buyer action it could support. Does the person compare availability, inspect a product, or reach a booking page? Then estimate the effort to keep the underlying information accurate. A feed that nobody owns after launch can create more operational work than its initial implementation suggests.
Keep the normal website baseline in the same plan: readable offer pages, working navigation, accurate business details, and a clear conversion path. Specialised discovery work should build on those fundamentals. Do not let a feature with unclear relevance displace a broken enquiry form.
Verify eligibility separately from appearance
A finished implementation has evidence that requirements were checked and the necessary data is correct. Actual appearance is another observation, recorded with query, market, device, and date. Neither a valid schema test nor a successful page request guarantees that Google will display a particular experience.
Revisit the map when your business model changes or Google updates the relevant guidance. A focused assessment can identify one worthwhile discovery or data-maintenance problem before a larger website build is commissioned.
Link Map
Sources and editorial review
Sources reviewed on 14 September 2026. The practical workflows and illustrative examples are JQ AI SYSTEMS analysis unless explicitly attributed.
- Google Search Central: Regional differences in Search experience (Updated 8 September 2026).