Google Merchant Center Store Address Feed Requirements

Isometric illustration of product packages and location pins connected through a digital feed to three separate retail stores.

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

Top-down illustration of products connected by color-coded lines to three miniature storefronts as a person checks the mappings.

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.

  1. Create or review a store master containing one current physical address for every location that participates in local shopping.
  2. Confirm that each local inventory record carries a stable reference to the correct store.
  3. Resolve that reference to the store’s address when the Merchant Center data is generated.
  4. Reject or quarantine local records whose store reference is blank, unknown, or linked to a missing address.
  5. 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

Illustration of a product record passing through a magnifying inspection checkpoint while a mismatched record is diverted for review.

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_address is 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


FAQs

Which product submissions require store_address in Google Merchant Center?

The requirement applies to products submitted for Local inventory ads, Local free listings, or both. It follows the individual submission, so a non-local record is outside this requirement unless it is also used for a local program.

What should the store_address value identify?

It should identify the physical store associated with the submitted product inventory. A headquarters, billing address, service area, store nickname, or warehouse label is not a safe substitute.

How should a multi-location retailer create the product-to-store mapping?

Maintain one controlled, current physical address for each participating store, give every local inventory record a stable store reference, and resolve that reference during export. Reject or quarantine records whose reference is blank, unknown, or linked to a missing address.

What if the same product is available at several stores?

Keep the store relationships separate so each applicable submission carries the address of the physical store tied to that specific inventory. Do not collapse all branches into one generic or account-wide default address.

How should store_address values be validated before submission?

Inspect the final serialized feed, confirm the field is present on every applicable record, and compare each value with the controlled address for its store. Check for blank, truncated, duplicated, or unexpectedly transformed values, then use Merchant Center feedback to catch remaining problems.

How should accented or non-Latin store addresses be handled?

Test those addresses through the complete export path because character handling can change between the commerce platform, feed tool, spreadsheet, and final file. If the location cannot be preserved correctly, hold the record and fix the source or encoding issue instead of inventing a transliteration or default.

How can a retailer roll out the store_address change safely?

Filter the feed to local-shopping records, count unresolved addresses, group records by store, and inspect samples from every location, especially products stocked in multiple branches. Trace at least one product per store through the finished export, make missing mappings fail validation, and review Merchant Center feedback after submission.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *