Browse Node Strategy on Amazon India: Nodes, Filters, Rank
A wrongly classified listing still sells, which is why nobody catches it. It just never reaches the filtered demand where intent is narrowest.
- Nodes control filters, rank and often the fee slab
- The Category Listings Report is your audit spine
- Item type keyword places you inside the refinements
- Flipkart verticals cannot be changed without a new listing
What a browse node actually controls
A browse node is the numeric address of your product inside the Amazon category tree. Most sellers treat it as cosmetic. It is not. The node decides which left rail filters your listing can appear in, which Best Sellers Rank you compete for, which category refinements advertisers reach you through, and in many cases which referral fee slab you sit in. In India those slabs run from roughly 2 percent to over 20 percent by category, so a misclassified catalogue is a margin problem as well as a discovery problem.
The loss is quieter than a suppression. A wrongly noded SKU still sells. It simply never enters the filtered result sets where narrow intent lives, and nobody notices because the listing looks healthy.
Audit with the Category Listings Report
Do not audit by eye. Request the Category Listings Report from inventory reports in Seller Central. It returns every active SKU with its current attribute values, including the assigned node and item type, in the same column structure as the upload template. It generates in minutes and costs nothing.
Then run four checks:
- SKUs with a blank recommended browse nodes field, which means the platform guessed on your behalf.
- Item type keywords that no longer exist in the current Browse Tree Guide, a common outcome after a category restructure.
- Nodes whose path contradicts the title, for example a mens shirt sitting under a womens node.
- Blank refinement attributes: size, colour, material, capacity, wattage, dietary flag, whichever ones drive filters in your category.
Item type keyword does the filtering work
Two fields carry most of the weight. The recommended browse nodes field takes the node ID. The item type keyword field places you into the refinement set inside that node. Get the node right and the item type wrong and you sit in the category but outside the filters. Leave the required attributes for that item type blank and the filters stay empty regardless of how good your node is.
Sequence the fix by traffic, not by SKU count. Take the top 50 SKUs by glance views, get their node and item type exactly right, fill every attribute the Browse Tree Guide marks as required, then work down the tail. A catalogue of 4,000 SKUs usually has 60 that matter this quarter.
Filtered traffic is worth the effort because the intent behind it is narrower. A shopper who has applied three filters has already told the platform what they will buy. Treat every filter you are absent from as a list of demand you were never shown to, and price the fix accordingly against what a click in that category costs you today.
Changing a node without breaking the listing
For most categories a partial update flat file carrying the SKU, the recommended browse nodes value, and the item type keyword is enough. Gated categories may need a case with seller support quoting both the current and the target node ID. Expect the attribute to reflect within a day and filter placement to settle inside 48 hours.
Two cautions. Moving nodes restarts rank history in the new node. And if the move crosses a fee boundary, your referral percentage changes with it, which you will see in the next settlement rather than in the listing. Pilot on five SKUs, hold price and advertising constant, and read glance views and unit session percentage for 14 days before you commit the rest.
Flipkart verticals are harder to undo
On Flipkart the equivalent decision is the vertical chosen when the listing is created. The vertical fixes the mandatory attribute set, the QC rules your catalogue is checked against, and the filters you can appear in. Moving a product to a different vertical generally means creating a fresh listing, which means a new product identifier, and ratings and reviews do not travel with it.
So the sequencing differs by platform. On Amazon you can correct a node and absorb a week of rank noise. On Flipkart you get the vertical right the first time or you pay for it in lost review depth for the life of the SKU. Download the category template before the first upload and make someone who knows the category sign off on the vertical.
Governance so it stays fixed
Classification decays. New SKUs get created by whoever is closest to the deadline, nodes get retired, and a clean catalogue drifts back inside two quarters. Four controls hold it.
- Name one owner for classification. Not a team, one person.
- Store the approved node ID and item type keyword against every SKU in your own master data, not only on the platform.
- Make node and item type a gate in the launch checklist, alongside images and pricing sign off.
- Re-pull the Category Listings Report monthly and the Browse Tree Guides quarterly, and diff them.
None of this is glamorous work. It is also the cheapest incremental traffic available to a brand that already has good listings, because you are not buying demand. You are removing the reason you were invisible to it.