Online store for children's goods: age, size, safety

The two numerical fields in each card are the age "from" and the age "to". Then querying "2 years" shows everything whose range covers that age, not just items with "2 years" in the title. If the age is a text in the description, you cannot remove the filter from it: first, the value has to be extracted from the entire catalog, and this is a separate work that we evaluate at the audit. A fair margin: A filter doesn't create demand for a product that isn't being searched for - it just lets you find what you already have.

By default, no. Size and height — variants of one model: one card, one canonical, choice in the card, balance at the level of the variant. Separate products for each size bloat the catalog and create duplicates that compete with each other for the same request. There is an exception: if a specific size has its own price, its own photos or a stable search demand, you can create a separate address for it - but pointwise, and not throughout the catalog.

One but with different card rules. Clothes live by size and height, food by expiration date, batch and "from" age, car seats by weight group and fastening method. We create these fields separately for each group, and the catalog frame, shopping cart and checkout remain common. An attempt to describe everything with one universal set of characteristics ends with half-empty cards: the filter formally exists, but there is nothing to filter.

In the product card, in a separate block, with the possibility to open the document. It makes no sense to hide it in the footer of the site - in the children's niche, it is the composition, material and availability of the document that is the reason for the choice. Technically, this is a field with a file that you fill in yourself: we cannot issue or check documents, this is the seller's responsibility. In the store we measured with a similar logic, the legal block is right in the card next to the characteristics, and the buyer reaches the decision without a manager.

Number of steps and page weight. The age filter should open with one touch, not through three menus; the number of items on the category page should be kept smaller than on the desktop, because each card pulls a photo. We measure this before launch: in a measured store with a similar type of purchases, the first response is 402.9ms with 303.4KB of HTML, and the spread across our sample is 126.3ms to 1,544.6ms on the same engine. Fair limit: the mobile version does not bring new people, it stops losing already brought ones. And by itself, the mobile viewport does not prove convenience - the real scenario is tested in live sessions.

A saved list of regular items and a repeat order button in the cabinet. These are consumables that are taken cyclically and almost without selection, so every extra step here costs an order. A subscription with automatic cancellation is also possible, but only if you are ready to conduct it as a process - with pauses, refusals and returns. And separately: to see the share of repeat purchases, you need analytics. In the store we measured with exactly the same sales model, there are no counters at all, that is, the main indicator of the niche is not counted in any way.

In the children's niche - yes, because some of the purchases are not made for one's child. The giver does not know the size or what is already at home, and needs a list that the parents have compiled themselves and sent to the link. Technically, this is a saved set of items with a public address and a "already donated" mark. We do not promise that this will raise the average check - we do not have our own measurement of such an indicator; what it does exactly is remove the question of "what to give" from correspondence with the manager.

25-45 working days from TOR approval, six stages: assortment audit 2-4 days, TOR and structure 3-5, design 5-9, assembly 7-12, import with attribute layout 5-9, markup with testing and transfer 3-6. It is not the code that stretches the project, but the attributes: extracting age and height from texts, building models from individual cards, arranging special fields into groups. If the data is already structured, the term runs along the lower limit.

No one promises items, and we will not. We close the technical part: CNC, canonical on size options, unique title, site map without duplicates and covering the entire catalog, JSON-LD with Product and Offer. The hole is most often here: in the two stores we measured /sitemap.xml gives HTTP 200 with a body of zero bytes, that is, the search engine does not receive the map at all. A fair margin: a clean sitemap and canonical do not add traffic — they stop spraying it between duplicates, and in the first weeks after cleaning, the number of addresses in the index may even drop. This is an expected course of events, not a glitch.