The Google Business Profile category configuration sets which queries a business is eligible for. Attributes, services, and products fill in what the business offers within that eligibility. The three fields look similar from the outside but do different jobs internally, surface in different parts of search results, and follow different policy rules. Most profiles get one or two right and leave the third either empty or filled out wrong. The fix starts with understanding what each field is for.
Three fields, three different jobs:
GBP attributes, services, and products are three distinct structured data layers on a Google Business Profile. Attributes are factual labels Google maintains in a closed taxonomy. Services are a free-text list of work the business performs. Products are structured catalog entries with images, prices, and descriptions. The fields are independent. Each surfaces in different places.
The independence matters because owners frequently treat the three fields as variations on the same theme. A restaurant might list “outdoor dining” as a service when it belongs in the attribute field. A roofing contractor might list “metal roof installation” as a product when it belongs in the service list. The fields aren’t interchangeable, and putting information in the wrong field reduces reach because Google reads each layer separately.
The simplest way to keep them straight: attributes describe what a business is or has; services describe what a business does; products describe what a business sells. A salon has wheelchair access (attribute), does balayage (service), and sells retail hair products (product). The same business uses all three fields for different parts of its operation.
Each field carries a different ranking weight:
The functional split between the three fields traces directly to how Google’s local index uses them. Attributes feed into filter-style queries (“dentists with wheelchair access” or “restaurants with outdoor seating”). Services match the body of intent queries (“balayage near me” or “metal roof installation Chicago”). Products surface in commerce-oriented searches and the GBP product carousel that appears in some categories.
Attributes carry the most predictable ranking weight because they’re booleans against Google’s filter set. A profile either has the “wheelchair accessible entrance” attribute or it doesn’t, and queries that filter on accessibility include only profiles that flagged the attribute. The matching is exact and binary.
Services and products are more open-ended. Google’s parsing of free-text service lists is fuzzy, and the matching weight in ranking depends on the language used. A service titled “balayage” matches “balayage” queries more cleanly than a service titled “creative color treatments” would, even if the operational work is the same. Specificity in service naming improves match quality for the query that names the service. Specificity in product naming has the same effect for product surfaces.
Each field rewards a different writing pattern. Attributes get checked off accurately. Services get named for the queries they’re meant to match. Products get described with the words customers use, not the internal product names.
Attributes are factual labels Google curates and the profile checks:
A GBP attribute is a predefined label from a closed list specific to each business category, used to flag verifiable factual properties (accessibility, payment types, amenities, services-included flags). The available attributes shift by primary category. A “Restaurant” primary unlocks attributes like “outdoor seating,” “accepts reservations,” and “serves vegan options.” A “Hotel” primary unlocks “free wifi,” “pool,” and “check-in time.” A “Dentist” primary unlocks “accepts new patients” and “languages spoken.”
The attribute list a profile sees is determined by the primary category, with some attributes appearing across multiple categories. Changing the primary changes which attributes are available, which is one of the reasons primary category selection has downstream consequences for profile completeness.
Attributes split into two types operationally. Owner-set attributes are flagged by the business in the profile dashboard. Crowd-sourced attributes can be added by customers through Google Maps prompts (“Did this place have outdoor seating?”) and surface on the profile if enough customers confirm them. Owners can override crowd-sourced attributes in the dashboard if they’re incorrect, but the override doesn’t remove the customer-facing source signal.
Two patterns of attribute misuse recur. The first is flagging attributes the business doesn’t offer in order to gain reach. Google’s spam systems and Maps customer reports both flag this; suspension risk is real. The second is leaving attributes unflagged that the business genuinely offers. This pattern is more common and costs reach without any upside; filter queries that should have included the profile simply don’t.
The audit for attributes is short: walk through every available attribute the primary category exposes, flag the ones that legitimately apply, and remove any that don’t or no longer apply. Twice a year is enough cadence for most businesses; quarterly for businesses whose operations change seasonally.
Services live in their own data layer:
The services field is a structured list of work the business performs, with each service taking a name, optional description, and optional price. Services are entered free-text rather than chosen from a Google list. The field surfaces in the profile under a “Services” section and feeds into ranking for related intent queries.
A profile holds dozens of service entries with descriptions and prices, though most businesses use only a fraction of the available slots. Some list ten services without descriptions; others list three services with full descriptions and prices. The richer approach produces better matching because the description text gives Google more language to associate the service with relevant queries.
The price field is optional and consequential. A service listed with a price is eligible for surfaces that filter or compare on price; a service without a price isn’t. For competitive categories where price comparison matters (auto repair, dental cleanings, salon services), missing prices means missing those comparison surfaces. The price doesn’t have to be exact (price ranges work, “starting at” prices work), but the field has to be populated to participate.
Service naming patterns that work reflect customer language rather than internal terminology. A dental practice’s internal name for a service might be “Class II composite restoration”; the customer-facing service name should be “Tooth-colored filling.” The internal name might be technically accurate; the customer-facing name matches the query. The customer-facing name goes in the title. The technical name belongs in the description.
For service-area businesses, services are particularly important because they substitute for the kind of visible-on-page work that storefronts get from photos of physical operations. A plumber’s services list functions as the public-facing catalog of work the business does; an empty services list leaves the profile less informative than the operations warrant.
Products surface as a separate visual carousel:
Products on GBP are structured catalog entries with images, names, descriptions, prices, and optional category groupings. They populate a product-specific visual carousel on the profile and in some local search results. The products field is most consequential for retail and e-commerce businesses; for service businesses without sellable items, the field sits unused.
The product setup is more structured than services. Each product entry has a required name and image, optional category (grouping multiple products), optional price, and optional description. Products with images outperform products without; the carousel is visual, and missing images either show placeholder graphics or skip the product in display.
The product carousel surfaces in three places. The profile itself shows products under a dedicated section. Some local search results show product cards inline when product-oriented queries trigger them. Google Maps shows products in the business listing when users tap to view more. The footprint is meaningful for retail, modest for most service categories.
Product entries pull double duty for shopping-oriented queries. A profile with products that match the query gets surfaced in shopping-tinged local results that wouldn’t trigger for profiles with empty product catalogs. The mechanism is similar to how attributes feed filter queries; products feed product-oriented queries.
The audit pattern for products is operational: keep the catalog small enough to maintain (50 products well-maintained beats 500 stale ones), keep prices current, swap images that have aged poorly, and remove products that no longer apply. A product catalog that contradicts the live inventory at the storefront is worse than no catalog.
The primary category decides which fields exist:
The set of available attributes, the format of services, and the availability of the products field all depend on the primary category. The dependency is one-way: the primary shapes the other fields, never the reverse. A “Pediatric dentist” primary unlocks medical-practice attributes and a services field with healthcare-appropriate fields. A “Plumber” primary unlocks service-area-business attributes and services without products. A “Clothing store” primary unlocks retail attributes and the full products carousel.
Setup order follows from this: the primary category is decided first, then the attributes/services/products configuration flows from what that primary makes available. Switching the primary after the structured fields are populated hides previously-flagged attributes that don’t carry over to the new primary, leaving visible gaps until the profile is reconfigured.
| Field | Primary category dependency | Best-suited business types |
|---|---|---|
| Attributes | High; available set changes per category | All businesses |
| Services | Medium; format adjusts but field exists across most categories | Service businesses, professional practices, contractors |
| Products | High; only available for retail and product-oriented categories | Stores, e-commerce, restaurants with merchandise, suppliers |
The asymmetry shows up most for hybrid businesses. A bakery that runs both retail and special-order operations needs to use products for inventory and services for custom work; both fields fill different parts of the operation. A bookstore that hosts events uses products for books and services for event hosting. Hybrid setups draw on multiple fields rather than picking one.
Edits don’t go live the moment you save:
GBP edits to attributes, services, and products go through a moderation process before they appear publicly. Delays range from instant to several days depending on the change type, the profile’s history, and category-specific scrutiny. The instant-edit pattern most owners expect doesn’t always hold.
Simple edits to existing services (description, price changes) go live within minutes. New service additions take hours to a day. New product additions go through image moderation and take longer. Owner-set attribute changes are instant. Crowd-sourced attribute additions surface faster than crowd-sourced removals; getting an incorrect crowd-sourced attribute taken down takes longer than getting one accepted.
The moderation pattern tightens for profiles with prior policy issues. A profile that’s been suspended and reinstated, or one with active flag history, sees longer delays and more rigorous review on every edit it submits going forward. Edits to attributes and services in those profiles trigger second-look reviews that wouldn’t apply to a clean profile.
For time-sensitive changes, don’t queue critical edits for the day they need to be live. Two to three business days is realistic for most edits; longer for businesses with prior moderation history.
What you can’t say without losing the profile:
GBP content policy applies to all three structured fields. Violations produce warnings, edit rejections, soft suspensions (the profile remains live but loses some features), or hard suspensions (the profile disappears from search until reinstated). The policy line shifts as Google’s enforcement priorities shift; the categories of violation stay stable.
Prohibited content categories include:
- Misleading or false claims about services
- Prohibited goods or services (regulated substances, weapons, certain financial products)
- Keyword stuffing in service names or descriptions
- URLs or contact info in fields not designed for them
- Offensive or discriminatory language
The most common policy issue in practice is keyword stuffing in service names. A roofing contractor lists thirty services that read like “roof repair Chicago, roof installation Chicago, roof inspection Chicago, emergency roof repair Chicago” with each city repeating. The pattern triggers Google’s spam systems; the services either get rejected at edit or the profile draws closer review. The clean alternative is service names that describe the service itself, with location signals coming from the GBP address rather than from the service name.
Recovery from policy issues runs on Google’s timeline, not the business’s. A rejected edit is corrected and resubmitted. A soft suspension (where the profile remains live but loses features like services display) recovers when the violating content is removed. A hard suspension requires a reinstatement appeal through the GBP support process, which takes weeks at best.
Manual GBP fields don’t sync; CMS fields do (sometimes):
The GBP dashboard fields are independent of the business’s website. Edits made on the website don’t propagate to the GBP automatically, and edits made in GBP don’t propagate to the website. Each system has its own data store. Keeping them aligned requires either manual cross-update or a sync layer.
Some CMS platforms offer GBP sync features through the Business Profile API. These features push service catalogs, attribute updates, and product changes from the CMS to the GBP automatically. The sync isn’t universal: each CMS supports a subset of GBP fields, and the API itself has limitations (it doesn’t support all attributes Google offers in the dashboard, doesn’t handle photo uploads as cleanly as manual upload, and doesn’t reflect crowd-sourced attribute changes).
For multi-location businesses, the case for API-based sync is stronger. Manually maintaining services and products across fifty locations is operational overhead that compounds. Sync tools (Yext, Birdeye, native integrations from larger CMS platforms) reduce that overhead but introduce their own coordination problem: when the sync source contradicts the GBP dashboard’s current state, the sync may overwrite changes the local owner made manually.
For most multi-location setups, the working approach is to pick a single source of truth for each field (the CMS for services and products, the GBP dashboard for attributes and operating hours), and discipline the team to only update the source. Edits made at the wrong layer get overwritten on the next sync.
Multi-location requires structural consistency:
A multi-location business’s attributes, services, and products configuration should follow consistent patterns across locations, with location-specific variation reserved for genuine operational differences. Inconsistency across locations is what breaks reach: some locations have full services lists, others have empty ones; some flag the same attributes, others don’t.
The consistency check splits into two layers. The structural layer asks whether each location has the same fields populated to similar depth (same service categories, same attribute coverage, similar product depth for retail locations). The content layer asks whether the specific entries reflect each location’s operations (a location that doesn’t offer a service shouldn’t list it).
For franchise operations and multi-brand portfolios, the consistency requirement creates governance overhead. A central marketing team owns the structural pattern; local managers own the content accuracy. The split works when each side respects the other’s domain. It breaks when local managers add services the central team doesn’t approve, or when central updates overwrite location-specific variations that exist for valid operational reasons.
The audit for multi-location setups is a comparison rather than a per-location check: across all locations, which fields are filled to similar depth, which show drift, and what does the drift indicate (operational difference vs neglect)? A location with markedly fewer services points to neglect; a location with markedly different attributes points to a real operational difference worth examining.
Where each field actually shows up:
The three fields appear in different parts of search results and the profile itself. The placement of each determines how much it affects what customers see. Each field has its own real estate. Knowing where a field shows up shapes how much effort to invest in it.
Attributes appear in three places: as small icons or text labels on the profile itself, as filter inputs in Google Maps search (the “Open now,” “Outdoor seating,” “Has wheelchair entrance” filters), and as eligibility signals in attribute-driven queries that produce filtered local packs. The filter-input role is the discovery lever; profiles with flagged attributes appear in filtered searches that exclude profiles without them.
Services appear in two places: a dedicated “Services” section on the profile, and as ranking signals for intent queries that match service language. The ranking signal is the lever for service businesses; the profile section is the secondary surface.
Products appear in four places: the dedicated “Products” carousel on the profile, the Google Shopping local inventory feed for businesses that connect inventory, product-oriented local pack results where the product carousel appears in SERP, and Google Maps product cards on mobile.
Prioritization follows from operation type: in service businesses, services field gets the most investment, attributes get the audit cycle, products get minimal effort. In retail, products get heavy investment, attributes get the audit cycle, services get whatever fits the operation. In hybrid businesses, the split depends on what proportion of revenue each side represents.
Categories define the search; attributes, services, and products define the answer:
The category configuration determines which searches a business is eligible to appear in. The structured fields determine how complete the answer is once the business is in front of a query. A profile with the right category and empty structured fields shows up but doesn’t differentiate. A profile with the right category and rich structured fields shows up and gives Google the depth to feature the business confidently across the local pack, the Knowledge Panel, and AI-generated local summaries that pull from the same underlying data. The category is the door. The structured fields are what’s behind it.
The mistake most setups make is treating structured fields as decoration. Attributes get flagged half-heartedly, services get listed as broad categories rather than specific work, products get added once and never refreshed. The result is profiles that exist but underperform their potential.
What makes the setup work isn’t doing all three fields at maximum depth. It’s matching each field’s investment to what the business offers and what its customers search for. The fields are structured because Google reads them programmatically; the writing pattern that produces results is matching that structure to operational reality.