Help Buyers Find Your Products: A Free Listings Playbook
A shopper in Pune searches for a cotton double bedsheet. Your store sells exactly that, but the shopper never reaches your website. You have photographs, prices and a working checkout; what may be missing is a reliable way to give Google structured information about those products.
Google Merchant Center free listings can provide that connection. You supply product information, connect it to your store and resolve eligibility issues. Eligible products may then appear in supported unpaid shopping experiences on Google. This is not a paid Shopping campaign, and acceptance does not guarantee exposure, clicks or orders.
For an Indian online store, the practical work is mostly catalogue maintenance: accurate identifiers, matching prices, useful delivery information and a website that customers can trust.
Key takeaways
- Check current country and feature eligibility before investing in setup.
- Choose one dependable product source instead of creating competing copies.
- Submit genuine product identifiers; never manufacture a GTIN.
- Keep each variant’s price, stock and landing page aligned.
- Treat shipping, returns and account issues as operational responsibilities.
- Assign an owner after launch; approval is not the finish line.
Understand what free listings can—and cannot—do
Merchant Center is Google’s system for receiving and managing information about products and the businesses selling them. A product source is the method used to supply that information, such as an ecommerce platform connection or a maintained file. Google evaluates the submitted information alongside the website and applicable policies.
Google’s free listings guidance explains the unpaid programme and its eligibility considerations. Check the current guidance for India, your product category and the particular feature you want to use. A supported country does not mean every product, placement or account automatically qualifies.
The important distinction is between eligibility and distribution. An eligible item can be considered for relevant appearances; it is not promised a particular position or number of impressions. A listing that receives little visibility is therefore not necessarily suffering from a technical error.
Free listings also do not require you to start a paid Shopping campaign. Paid campaigns involve advertising budgets and separate campaign decisions. If you later evaluate that route, our Google Performance Max guide for India covers a different subject, not a prerequisite for this playbook.
Editorial recommendation: begin with the goal of building an accurate, maintainable catalogue. This gives you something controllable to improve before making assumptions about traffic. Decide separately how you will evaluate visits and orders, without treating either as guaranteed outcomes.
Check your store before connecting the catalogue
Start with the buying journey, not the upload. Open a product page on a phone, select a variant, add it to the basket and proceed through checkout. Check whether the product is genuinely purchasable and whether important conditions appear before the customer commits.
Your website should clearly identify the business, explain how customers can contact it and provide accessible shipping and returns information. Product pages need understandable descriptions, accurate prices and availability, and images that represent what is being sold. A polished homepage cannot compensate for broken product links or an unusable checkout.
Prepare access to your store administration, domain verification tools where needed, catalogue data and Merchant Center account. Google may require you to verify and claim the website associated with the account. Follow the instructions available for your setup rather than relying on an old tutorial’s menu labels.
Check the policies applicable to your products before importing them. Some categories face restrictions or additional requirements; having sold something successfully on your own site does not establish its eligibility for Google’s shopping experiences. Do not assume another seller’s visible listing proves your item is permitted.
Editorial recommendation: resolve store-wide weaknesses before uploading hundreds of products. Use our product-page audit for Indian online stores to organise the website review. Keep a written list of blockers, with a named person responsible for each correction and a specific way to confirm the fix.
Choose a product source you can maintain
The best product source is the one your team can keep accurate when prices, stock and variants change. A platform integration can be convenient when your ecommerce system already contains clean product information. A file-based source can suit a smaller catalogue, provided somebody reliably updates and submits it.
Other supported methods may include automated website-based collection or API connections, depending on the account and current tools. An API is a software connection that transfers information between systems. It can support more complex operations, but it also creates an engineering responsibility when authentication, mappings or updates fail.
Do not select a method purely because initial setup looks quick. Ask how it handles sale dates, deleted products, unavailable variants, shipping attributes and errors. Also establish how often changes reach Merchant Center; “connected” does not necessarily mean every change appears immediately.
Google’s product data specification defines the attributes used to describe products and explains when they are required. Use it as the reference for your chosen method. A spreadsheet column label or platform field should map to the intended attribute, not merely resemble its name.
Editorial recommendation: designate one authoritative source for each product field. For example, your inventory system might own stock while your ecommerce catalogue owns titles. Avoid submitting the same items through several overlapping methods without understanding their interaction: conflicting prices and duplicate identifiers become much harder to diagnose.
Before expanding, test a representative selection containing an ordinary item, a variant family, a sale item and an unavailable product. Confirm that each arrives with the intended values.
Get product and variant identifiers right
An item ID is your stable identifier for a submitted product. A GTIN, or Global Trade Item Number, identifies a trade item and is commonly represented by a retail barcode. These serve different purposes: your internal stock code cannot simply be relabelled as a GTIN.
Use genuine GTINs assigned to the exact products you sell. Obtain them from reliable manufacturer or supplier information and check that they match the packaging, size, colour or pack configuration. A barcode copied from a similar product is still the wrong identifier.
Never fabricate digits to fill a missing GTIN field. Do not borrow a competitor’s identifier, recycle one from another variant or assume that passing a format check makes a number genuine. Incorrect identifiers can misrepresent the item and create problems that are harder to trace than an honestly missing field.
Some products genuinely lack manufacturer-assigned unique identifiers. Google’s specification explains how brand, GTIN, MPN and the identifier_exists attribute apply in different circumstances; MPN means manufacturer part number. Follow those rules for the actual product rather than declaring identifiers absent simply because your supplier has not yet answered.
Keep variants separate but related
A variant is a particular version of a product, such as a blue kurta in size M. Submit distinct purchasable variants with distinct, stable item IDs. Where applicable, use a shared item_group_id to identify the family, alongside the attributes that distinguish its members.
Each variant should lead to a page that clearly identifies the advertised version, preferably with that option selected. Its image, price and stock status must describe that version. Editorial recommendation: maintain a variant register so staff cannot accidentally reuse a retired ID for an unrelated product during the next catalogue cleanup.
Write product information for a purchase decision
A useful title helps someone distinguish this product from nearby alternatives. Start with the product identity, then add attributes that materially affect selection: brand where appropriate, material, size, colour, model or pack quantity. Use the same underlying facts that customers can verify on the landing page.
Avoid turning titles into promotional banners. Phrases such as “best deal ever” do not explain whether a buyer receives one cushion cover or a set of four. Repeating synonyms also makes the title less readable without resolving uncertainty about the actual item.
Google’s product data optimisation guidance covers ways to improve submitted product information. Treat optimisation as increasing accuracy and usefulness, not as a promise of better placement. Meeting a data-quality recommendation cannot guarantee that a product will appear for a particular query.
Descriptions should explain what is included, important specifications and relevant limitations. For a bedsheet set, that might mean dimensions, fabric composition, included pillow covers and care instructions, provided those facts are known. Do not invent qualities such as colourfastness or organic certification to make sparse supplier copy more persuasive.
Use images that accurately represent the item and selected variant, and check the current image requirements in the specification. Look particularly for misleading bundle photographs: if the image shows decorative accessories that are not included, the overall presentation should not suggest otherwise.
Editorial recommendation: improve one product family at a time. Agree on a reusable title pattern and description checklist, while preserving meaningful differences between products instead of copying identical text everywhere.
Make price and availability match the destination
The price in Merchant Center should agree with the price of the advertised product on its landing page and through the applicable buying journey. For Indian shoppers buying in rupees, ensure the submitted currency and destination pricing are aligned. Review the current specification for applicable tax and pricing rules rather than adapting assumptions from another country.
Variant selection is a common source of confusion. A family page may display a low starting price while the submitted variant costs more. If Google receives the larger size’s price but the link opens an ambiguous “from” price, the relationship between the listing and the purchasable item is unclear.
Sale prices need coordination too. Where you use sale-price attributes and effective dates, make sure the website promotion and source updates follow the same schedule. Check both the start and the end of an offer; expired discounts can remain in a file long after the store has restored its normal price.
Availability should describe whether the advertised item can actually be purchased under the stated conditions. Do not mark an unavailable size as in stock because other sizes remain available. If you support preorder or backorder, use the applicable values and accompanying information required by the current specification.
Automatic item updates, where available and enabled, may help address certain discrepancies using website information. They are not a substitute for maintaining the original source. If the catalogue repeatedly sends stale stock, investigate the update process rather than expecting another system to repair it indefinitely.
Editorial recommendation: test synchronisation after a real price or stock change. Record the website value, submitted value and time checked so you can identify whether the delay originates in your store, connector or processing.
Explain shipping and returns before the surprise
Shipping settings should represent the delivery service customers can actually buy. Check the current requirements for your target country and configure the supported account-level or product-level information accordingly. Where delivery varies by product, destination or order conditions, avoid a simple default that misstates those differences.
For an Indian store, this means thinking carefully about serviceable destinations and PIN-code checks. If a product cannot be delivered to a shopper’s address, the website should make that limitation understandable before payment. Do not present nationwide delivery merely because it sounds more attractive than your actual coverage.
Separate handling time from transit time when planning your information. Handling is the period before dispatch; transit is the carrier journey after dispatch. A promise based only on a courier’s fastest journey can overlook the days your store needs to prepare the order.
Returns information should explain the policy customers will encounter, including relevant conditions, time limits, costs and the process for requesting a return. If different products have different policies, make those distinctions clear. Do not submit a generous default that contradicts exclusions on the product page.
Editorial recommendation: test three realistic baskets: below a free-shipping threshold, above it and containing an item with special delivery conditions. Compare the stated delivery charge with checkout. When shipping or returns information changes, update the website and the applicable Merchant Center settings or product data required for your setup, then verify the result. Check Google’s current specification to determine which details belong in product data and which are managed elsewhere.
Make website trust practical, not decorative
Trust comes from being able to understand who is selling, what will arrive and what happens if something goes wrong. Check that business identity and contact information are consistent across the website and Merchant Center. Do not hide essential information inside an image that is difficult to read on a phone.
Review product pages as a first-time buyer, not as someone who knows the business. Can a visitor identify the included quantity, select the intended size and find delivery and return conditions? Are broken links, contradictory messages or unexpected checkout steps creating avoidable uncertainty?
Remove claims you cannot substantiate. Invented reviews, unsupported endorsements and copied certification badges are not substitutes for dependable information. Likewise, a generic policy template may describe return options or dispatch practices that your business does not actually offer.
Technical access matters as well. Check whether important product information loads reliably and whether relevant pages are accessible to Google’s systems. Authentication walls, errors or badly implemented redirects can interfere with evaluation even when a staff member’s logged-in browser looks fine.
These are practical review recommendations, not a complete statement of Google’s policies or legal advice. For broader website discoverability, see our ecommerce SEO guide for India. Website SEO and Merchant Center maintenance can support the same catalogue, but neither replaces the other’s checks.
Triage diagnostics by scope and cause
After processing, review the account’s product and policy issue information. Interface names can change, so work from the current explanations shown in your account rather than searching for a fixed menu path. Read the affected destination, products and stated reason before making changes.
First separate account-wide issues from item-specific issues. A business or website problem can affect a large part of the catalogue; a missing attribute may affect only certain variants. Fixing isolated titles while ignoring a broader account restriction is unlikely to address the main blocker.
| Issue pattern | First check | Practical next step |
|---|---|---|
| Price mismatch | Exact variant and active promotion | Align source and destination price |
| Availability mismatch | Variant stock and update timing | Repair the stock mapping or sync |
| Identifier issue | Manufacturer data for the exact item | Correct genuine identifiers; do not invent |
| Shipping inconsistency | Submitted conditions versus checkout | Reconcile rates, coverage and conditions |
| Account-level concern | Stated policy issue and website evidence | Resolve the underlying business or site issue |
Next, trace a sample affected item from its original record through the submitted data to the live page. This reveals whether the problem is a missing source value, a connector transformation or a website inconsistency. Correcting only the visible symptom can leave the next scheduled update free to reintroduce it.
Keep a small issue log with the affected scope, suspected cause, owner and verification result. When a review process is available, follow its instructions after making the necessary corrections. Do not repeatedly request review while leaving the underlying issue unchanged.
Finally, distinguish warnings, disapprovals and low visibility. Their meanings and effects are not interchangeable. Editorial recommendation: clear eligibility blockers first, then improve incomplete but valid data, then investigate performance questions using reporting available for the relevant destination.
Work through a hypothetical variant problem
Consider a hypothetical Indian store selling one bedsheet design in three colours and two sizes. That creates six purchasable variants: three multiplied by two. Each variant has its own item ID, and the related variants share the appropriate group identifier.
The single-bed size costs ₹799 and the double-bed size costs ₹999. Assume checkout charges ₹60 shipping for orders below ₹1,500 and no shipping charge at or above ₹1,500. These are invented operating details for this example, not recommendations or market benchmarks.
A customer buying one double-bed sheet would pay ₹999 plus ₹60, totalling ₹1,059. Two double-bed sheets would cost ₹1,998 and meet the hypothetical free-shipping threshold. The product price remains distinct from the shipping charge; the submitted shipping information needs to reflect the store’s actual threshold conditions.
Now suppose the blue double-bed variant sells out, but the product source still marks all six variants in stock. Five remain available; the sixth is incorrectly represented. The fix is to update that variant’s availability, not to remove the entire design or mark every colour unavailable.
Suppose also that its link opens the single-bed option at ₹799. The store must correct the destination behaviour so the advertised double-bed variant is clearly identifiable. This example illustrates two separate checks—stock and variant selection—not a forecast of clicks, sales or approval after correction.
Use a worksheet before approving a product family
Copy the following worksheet into a shared document. Complete it for a representative product family, then use it whenever you introduce a new category, connector or variant structure. Its purpose is to expose decisions that otherwise remain in someone’s memory.
Product-family readiness worksheet
- Family name and reviewer: Who checked it, and on what date?
- Selling destination: Which country and free-listings feature have you checked for current eligibility?
- Source and owner: Which system sends the data, and who maintains it?
- Variant structure: What changes between variants, and which stable IDs identify them?
- Identifier evidence: Where were the genuine GTIN, brand and MPN details obtained, where applicable?
- Landing-page test: Does each sampled link identify the advertised variant?
- Commercial match: Do price, currency, sale timing and availability agree?
- Delivery test: Which destination and basket were checked against shipping information?
- Returns and contact: Are the applicable policy and seller contact details accessible?
- Open issue and retest: What remains unresolved, who owns it, and how will the fix be verified?
Do not use “looks fine” as the final evidence. Record the variant checked and the observed values. A specific note such as “double-bed blue, ₹999, unavailable on both source and page” is more useful than a general approval of the whole catalogue.
Editorial recommendation: require an explicit handover when someone else must complete a field. An unanswered identifier question belongs with the person who can verify supplier information, while a broken variant link may belong with the website maintainer. The worksheet should route work, not merely accumulate unchecked boxes.
Launch in stages with clear exit checks
A staged launch makes mistakes easier to isolate. The stages below are an editorial operating plan, not a Google-mandated timetable. Move forward when the checks pass rather than because a particular number of days has elapsed.
Stage one: establish store readiness
Review policy eligibility, business information, product pages, checkout, shipping and returns. Confirm access to the necessary accounts and website controls. Exit this stage when there are no known purchasing blockers and the team understands what information must be supplied.
Stage two: connect representative products
Choose the source and send a manageable selection that includes common edge cases. Include variants, a sale item and any product with different shipping conditions. Exit when the processed data and live destinations describe the same purchasable items, with no unresolved critical issues in the test selection.
Stage three: expand by product family
Add more families using the same checks, rather than assuming one successful item validates every mapping. Watch especially for missing identifiers, inconsistent size naming and images inherited from the wrong parent product. Pause expansion if a repeated problem suggests the source needs repair.
Stage four: prove maintenance works
Make or observe ordinary catalogue changes, then confirm they reach the submitted data correctly. Test how discontinued items and unavailable variants are handled. Exit when the responsible person can explain both the update process and the response to a failed update.
Keep performance evaluation separate from these readiness checks. After the catalogue is eligible and stable, review the available free-listings reporting and website analytics. A technically clean launch establishes a useful foundation; it does not establish that demand, competitive appeal or exposure will be sufficient for your commercial goals.
Assign ongoing ownership and review triggers
Free listings need an owner even when a connector handles routine transfers. Assign one person responsibility for checking issues and coordinating corrections, while identifying who controls stock, prices, product copy and website changes. In a small business, one person may hold several roles, but the responsibilities should still be explicit.
Set a review frequency that matches how quickly the catalogue changes. A store with frequent stock movements needs a different routine from one selling a small, stable range. As an editorial starting point, review after important commercial changes and conduct a regular account check rather than waiting for traffic to fall.
Create event-based triggers too. A new theme, domain change, checkout update, sale launch, shipping-rate change or connector replacement can affect previously correct information. Include Merchant Center verification in the release checklist for those changes.
Watch source health as well as product status. A successful transfer yesterday does not prove today’s transfer completed, and a sharp catalogue-count change deserves investigation. Keep basic records of update failures and recurring errors so the team can distinguish a one-off omission from a systemic problem.
When reviewing results, use metrics actually available in your account and analytics setup. Keep unpaid listing activity separate from paid campaign activity where reporting allows. Editorial recommendation: make each review end with a decision—repair, test, improve or continue monitoring—rather than producing a report that nobody acts on.
Frequently asked questions
Are free listings really free, or must I buy Google ads?
Free listings are unpaid listings; buying a Shopping campaign is not a prerequisite. Your business may still incur costs for its website, staff time, integrations or outside help. Those operating costs are different from paying Google for advertising placement, and neither setup nor spending guarantees free-listing exposure.
What should I do if my supplier has not provided a GTIN?
First establish whether a genuine GTIN exists for the exact item. Ask the manufacturer or supplier and check reliable product documentation or packaging. If the product genuinely has no assigned identifiers, follow Google’s current specification for the applicable identifier fields; do not fabricate a number or automatically declare every missing identifier nonexistent.
Why is an eligible product not getting impressions?
Eligibility means the product can be considered, not that it must appear. Check the relevant destination status, unresolved issues and available reporting before assuming the upload failed. Then review whether the product data accurately describes the item and supports relevant buyer decisions; there is no responsible promise of a visibility increase from a particular edit.
Can I upload a file once and leave it alone?
Only if you can also keep the information current through the source’s supported maintenance process—and even an unchanged catalogue needs oversight. Prices, stock, delivery conditions and website behaviour can change independently. Choose an update method and review routine that prevent old data from remaining live unnoticed.
Source note: This guide draws on Google’s product data specification, free listings guidance and product data optimisation guidance. Consult those living documents and your account’s current notices for applicable requirements, country support and feature eligibility. The worksheet, triage order and staged operating plan are editorial recommendations.
Need help turning catalogue and website issues into a manageable worklist? Contact Adservex to discuss your store’s setup.
The Adservex editorial team writes practical marketing guides for Indian brands, reviewed against our editorial standards.
Published by Adservex. Examples illustrate decisions, not guaranteed outcomes. Platform requirements can change.



