If you submit products for Google’s local shopping experiences, a store name or internal location code is no longer enough by itself. Each applicable product submission needs a store_address value that identifies the physical location associated with that inventory.
The difficult part isn’t typing an address. It is making sure every local product record resolves to the right store before the feed leaves your system. For a retailer with several locations, a careless default can associate a large part of the catalog with the wrong branch.
Which product submissions need store_address
The requirement applies to products submitted for Local inventory ads and Local free listings. Local inventory ads are paid placements for products available at nearby physical stores. Local free listings provide an unpaid route into Google’s local shopping experiences.
The requirement follows the submission, not merely the Merchant Center account. A merchant using a mix of local and non-local shopping programs should therefore identify which exported records are intended for a local experience instead of applying an arbitrary address to the entire catalog.
- Is this product submission intended for a Local inventory ad, a Local free listing, or both?
- Which physical store does the submitted inventory belong to?
- Does the exported record contain that store’s physical address?
- Can the record still resolve to the correct address when the same product is stocked at several locations?
If the answer to the first question is no, this particular local-inventory requirement is outside that submission’s scope. If the answer is yes, treat the address as required data rather than optional descriptive information.
Build the product-to-store mapping before editing the feed

The store_address attribute is meant to identify the physical store associated with a product. That makes this a relationship problem: product, inventory record, store, and address all need to agree.
A practical implementation separates the permanent store data from the feed transformation. Keep one controlled address for each physical store, connect every local inventory record to the appropriate store, and populate store_address from that store record during export. This avoids maintaining thousands of copied address values independently.
- Create or review a store master containing one current physical address for every location that participates in local shopping.
- Confirm that each local inventory record carries a stable reference to the correct store.
- Resolve that reference to the store’s address when the Merchant Center data is generated.
- Reject or quarantine local records whose store reference is blank, unknown, or linked to a missing address.
- Keep non-local submissions outside this transformation unless they are also intended for a local program.
When one product is available in several branches, do not collapse those relationships into one generic address. Each applicable submission should carry the address of the physical store associated with that specific inventory. A headquarters address, billing address, service area, store nickname, or warehouse label is not a safe substitute for the required physical location.
Validate the value that Merchant Center actually receives

Google defines store_address as a string using Unicode characters and calls for the address to be formatted as ASCII-encoded text. Because character handling can change as data moves through a commerce platform, feed tool, spreadsheet, or export process, inspect the final serialized value rather than relying only on what appears in your store database.
- Check that the field is present on every applicable local product record.
- Compare the exported value with the controlled physical address for that store.
- Look for blank, truncated, duplicated, or unexpectedly transformed values.
- Test addresses containing accented or non-Latin characters through the complete export path instead of assuming every system handles them identically.
- Use Merchant Center’s resulting feed feedback to find values that your internal checks did not catch.
Do not silently invent a transliteration or replace an uncertain address with a convenient default. If the export cannot preserve a location correctly, hold that record back and resolve the encoding or source-data problem. A plausible but incorrect address can be harder to notice than an empty field.
Key takeaways
store_addressis required for product submissions intended for Local inventory ads and Local free listings.- The value must identify the physical store associated with the submitted product inventory.
- Multi-location retailers need a dependable product-to-store-to-address mapping; one account-wide default is not enough.
- Missing or incorrectly formatted addresses can interfere with product-to-store association and feed compliance.
- Validation should inspect the final exported data, not just the address stored in the commerce system.
Roll out the change without creating false store associations
Start by filtering your feed to the records used for local shopping. Count how many lack a resolvable store address, group the remaining records by location, and inspect samples from every store. Pay particular attention to products stocked in multiple branches, because that is where a generic fallback is most likely to create an incorrect association.
Then make the validation repeatable. Your feed process should stop an applicable local record when its store reference or address is missing, rather than letting that record inherit whichever address happens to be available. After submission, review Merchant Center feedback for address and association problems before assuming a successful upload means every product is tied to the right location.
The next useful action is simple: produce a list of every physical store participating in your local programs, confirm its controlled address, and trace one product from each store through the finished export. Once those paths are correct, enforce the same mapping rule across the full local inventory feed.
References


Leave a Reply