Ecommerce Website Development in Pune: Back-in-Stock Alerts, Wishlists and Out-of-Stock Product Pages

Ecommerce Website Development in Pune: Back-in-Stock Alerts, Wishlists and Out-of-Stock Product Pages

An out-of-stock product page should stay live at its original URL, say clearly that the item is unavailable, mark the offer as out of stock in structured data, and give the visitor something useful to do next: join a notify-me list, save the item to a wishlist, or see close alternatives. Deleting the page or redirecting it to the home page throws away the search visibility and links that the product has earned. For anyone planning ecommerce website development in Pune, the technical work splits into four parts: how the page behaves for search engines, how the notify-me form is designed, how consent is captured for email and WhatsApp alerts, and how stock changes trigger sends without duplicates or spam.

This guide is for store owners and developers running Shopify or WooCommerce who sell products that go out of stock regularly: apparel drops, handmade goods, electronics accessories, supplements, books. It covers behaviour and design, not shipping, payments or tax. Search guidance is summarised from Google's documentation as read in October 2026. Privacy points are not legal advice; check your own obligations with a qualified adviser.

What this article does not repeat

We have already written about abandoned cart recovery, about Product schema on Shopify and WooCommerce, and about upsells, cross-sells and bundles. Here we touch schema only for the availability field, and we treat upsell-style suggestions only as the "similar items" block on a sold-out page. The focus is the shopper who wanted something you cannot sell today.

What should an out-of-stock product page do?

A sold-out page is still a landing page. People arrive from Google, from a saved link, from an Instagram post or from a WhatsApp message a friend forwarded. Each of them wanted this product. Four things matter on that page.

1. Say so plainly, near the title. "Currently out of stock" in text, not only a greyed button. If you know the likely restock window, say it as a range ("expected in 2 to 3 weeks") and only if it is real.
2. Replace the buy button with a useful action. Usually that is a notify-me form. For items that will never return, offer alternatives instead.
3. Keep the product information. Description, images, size guide, reviews and specifications stay. This is what keeps the page useful to a person and to Google.
4. Show alternatives. A short row of in-stock items from the same collection, in the same price band or with the same use.

What the page should not do: auto-redirect to the category, show a generic "page not found" body while returning a normal status, or hide the product while leaving an old link to it in your own menus.

Three kinds of unavailable

Not every "out of stock" is the same, and the page should reflect which one it is.

How out-of-stock pages should behave for SEO

Keep the URL, do not return 404 for a temporary gap

Google's guidance on ecommerce URL structure recommends long-term, persistent URLs. It does describe a 404 response for an empty category that your site removes automatically, which tells you where the line sits: a 404 is for pages that are truly gone, not for items that will be back next month. If a product is coming back, the URL should be 200 throughout.

Soft 404 risk

Google defines a soft 404 as a page that returns a success status code but whose content looks like an error or an empty page. Reporting on a Google Office Hours answer (via Search Engine Journal) says Google's John Mueller indicated that a product page can be treated as a soft 404 when the page reads as unavailable and adds little else, and that the effect was described as theoretical rather than certain. We could not find a Google transcript, so treat the exact wording as secondary. The practical lesson is safe either way: do not strip a sold-out page down to a title and a disabled button. Keep the description, images, reviews and a related-products block so the page still has value of its own.

Set availability in structured data

Google's merchant listing documentation lists the supported availability values for an offer: InStock, OutOfStock, BackOrder, PreOrder, PreSale, SoldOut, Discontinued, LimitedAvailability, InStoreOnly and OnlineOnly. You must not specify more than one value. For a sold-out product with a restock plan, the right value is OutOfStock (or SoldOut); for backorder items, BackOrder; for items that are gone for good, Discontinued.

A minimal example for a temporarily unavailable item:

"offers": {
  "@type": "Offer",
  "price": "1499",
  "priceCurrency": "INR",
  "availability": "https://schema.org/OutOfStock",
  "url": "https://example.com/products/cotton-kurta-indigo"
}

Two cautions. First, keep markup consistent with what a visitor sees on the page; the visible text says out of stock, so the markup should too. (Google's page we read did not spell out that rule in the section we could check, so this is our own recommended practice rather than a quoted requirement.) Second, make sure the value updates when stock changes. Themes that hard-code InStock are a common cause of mismatch. Our product schema guide shows where each platform generates that field.

Google's product structured data page also says that providing availability data helps customers know when you have a product in stock, and it is part of what lets product results show stock information.

What to do with each situation

• Temporary out of stock: keep 200, keep indexable, mark OutOfStock, add notify-me.
• Seasonal product: keep the URL all year. The page that carried reviews and links in December should still be there next December.
• Discontinued with a direct successor: a 301 redirect to the successor product is reasonable when the two are genuinely equivalent. Redirecting everything to the home page confuses people and sends them somewhere they did not ask to go.
• Discontinued with no replacement: keep it for a period with alternatives and a Discontinued marker, then return 404 or 410 once it has no traffic, links or purpose.
• Empty or near-empty collection pages: follow Google's guidance of noindex or a 404 where a category genuinely has nothing to show, but do not do this to a collection that is only briefly sold through.

Ecommerce website development in Pune: native platform options versus apps

This is the section most likely to go out of date, so check the current admin and documentation before you commit.

Shopify

Shopify's help centre says that once inventory tracking is on, you decide what happens when a product runs out, including the option to continue selling out-of-stock items. That setting is how pre-orders and backorders are usually done. For back-in-stock alerts, the third-party guides and app listings we found describe an app as the normal route, and the app listings (for example the AlertMe and GrootApps listings on the Shopify App Store) show a notify-me button on the product page with email, SMS or WhatsApp alerts and some automation. We could not confirm from Shopify's own help pages whether a native notify-me feature or Flow template exists today, so check the current Shopify documentation and your plan before assuming you need an app.

WooCommerce

WooCommerce lets you manage stock per product and per variation, and offers stock statuses of in stock, out of stock and on backorder. Backorder behaviour is a per-product setting, and variable products carry stock per variation, so one size can sell out while the parent product still looks available. Notify-me functionality has historically come from paid extensions or plugins rather than core stock settings, but we did not confirm the current extension line from an official page, so check WooCommerce's documentation and compare options before buying.

Comparison

A reasonable rule is to start with an app if your catalogue is under a few hundred products and you have no CRM yet, and to move to a custom or CRM-led build when alerts, wishlists and customer records need to live together. Our Shopify versus WooCommerce comparison covers the platform choice itself.

Designing the notify-me form

The form is small, so every choice in it matters.

Place and label

Put it where the buy button was, above the fold on mobile. Label it "Notify me when available" rather than "Subscribe". The promise is narrow: one message about one product.

Fields

• One contact field. Either email or mobile number, with a choice if you offer both. Do not ask for a name.
• Variant selection. If the item is out of stock only in size M, capture size M. A shopper who gets a "back in stock" alert for the wrong size will not trust the next one.
• Optional quantity or pincode? Skip them. They add friction and are not needed to send an alert.
• Channel choice. Two unchecked options, email and WhatsApp, with the shopper choosing. Never pre-tick WhatsApp.

Confirmation

After submission, show a plain confirmation: "We will message you once, when this size is back in stock." If you also plan to use their details for anything else, ask separately. Mixing a one-off alert with newsletter enrolment is the commonest way to turn a good feature into a complaint.

Consent for email and WhatsApp alerts

What the platform expects

Meta's WhatsApp opt-in documentation says a business must clearly state its name, get opt-in permission before messaging, tell the person what they are opting in to, and honour opt-out requests. It also says the business can choose its own opt-in method, including a website, as long as those requirements are met. For notify-me, that means the form should name your store and say what will be sent, for example: "[Store name] will send one WhatsApp message when this item is back in stock." Our WhatsApp opt-in compliance checklist goes through the wording and record-keeping in detail.

India's DPDP Act and Rules

The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025, with commencement staggered. Reporting from EY and Mondaq on the Rules says the core consent and notice obligations (including Rule 3's notice requirements) come into force about 18 months after notification, which is 13 May 2027, with consent manager registration earlier. The same summaries say the notice must itemise the personal data, state the purposes and give a link where the person can withdraw consent with ease comparable to giving it. These are secondary summaries; confirm dates and wording against the Gazette text and take legal advice. Challenges to the framework were reported to be pending, so check for updates.

Whatever the date, the design implication is practical and cheap to build now:

1. Record what was agreed: contact detail, product and variant, channel, timestamp, the exact consent text shown and the page URL.
2. Use the data only for that purpose. An alert request is not a marketing newsletter sign-up.
3. Put an unsubscribe or "stop" instruction in every message, and make withdrawal as easy as sign-up.
4. Delete the request once you have sent the alert, or after a stated period if the item never returns. Holding on to numbers indefinitely is both a risk and clutter.
5. Link a short privacy notice next to the form, written in plain language.

Email versus WhatsApp

Because a restock alert is sent after the customer asked for it, it is closely tied to their request. Whether Meta classifies a particular template as utility or marketing is Meta's decision, and it can change; read our explanation of utility versus marketing templates and keep the wording factual and specific to avoid rejections.

Wishlists: what they are for

A wishlist is a different intent from a notify-me request. Notify-me says "I want this and cannot get it." A wishlist says "I might want this later." Treat them as two features that can share a data model.

Minimum viable wishlist

• A heart or "Save" icon on product cards and product pages.
• Works without an account (stored in the browser) and syncs to the account if the shopper logs in later.
• A saved-items page with stock status shown for each item.
• Optional alert preferences: "tell me if this goes out of stock" or "tell me when this is back", each off until chosen.

Inventory sync and trigger logic

An alert is only as good as the stock number behind it. The most common failure is alerting when the stock is technically above zero but physically gone, or alerting for a variant that is still out.

Define "back in stock"

Write the rule down. A good default: send when available quantity for that exact variant rises from zero to at least a threshold you choose, and the product is published and purchasable. A threshold above one (say, three units) avoids alerting when a single return pops back into stock and sells out in seconds.

Source of truth, duplicates and spam

Keep one system as the stock source of truth, and drive alerts from that record rather than a manual theme toggle. Then:

• One alert per request. Mark the request as sent and close it. Do not re-send when stock flickers.
• Debounce. Wait a few minutes after a stock change before sending, to absorb corrections.
• Cap per recipient. A person with ten open requests should not receive ten messages in a minute; combine or space them.
• Suppression list. Unsubscribes and WhatsApp stops are respected across every product.
• Log every send with the stock value at send time, so support can answer "why did I get this?"

Speed impact of alert and wishlist features

Notify-me and wishlist widgets are often loaded as third-party scripts on every product and collection page. Google's web.dev guidance on Interaction to Next Paint says to aim for 200 milliseconds or less at the 75th percentile, and notes that script evaluation can cause long tasks and that iframes with their own main thread count toward INP. A heavy widget that loads on every card can hurt that score.

Practical steps:

• Load the form code only on product pages that are actually sold out.
• Defer wishlist code until first interaction on collection pages, or ship the heart icon as plain HTML and load logic on tap.
• Avoid one request per product card to check wishlist state; send the list once.
• Test with and without the app using real mobile conditions. Our store speed and Core Web Vitals guide covers how to measure.

A hypothetical worked example

This example is invented for illustration; the numbers are not from a real store.

A Pune-based handloom shop sells about 120 products. A popular indigo kurta sells out in sizes M and L every month. Before the change, the sold-out page showed a greyed button and sent visitors to a contact form.

What they did:

1. Kept the URL live, marked offers as OutOfStock per variant, and kept the description and reviews.
2. Added a notify-me form with two unticked options (email, WhatsApp) and the exact consent line naming the store.
3. Stored size, channel, consent text and timestamp with each request.
4. Set the alert rule: send when a variant reaches at least 4 units, in sign-up order, in batches of 10, once per request.
5. Added a related-items row of in-stock kurtas in the same price band.
6. Loaded the form code only when the product is out of stock.

What to measure (not promised): sign-ups per sold-out page view, alert-to-purchase rate, unsubscribe and block rate, and complaint count. If the block rate on WhatsApp climbs, the wording or timing is wrong. Compare page speed before and after the app is added.

Build checklist

• Sold-out pages return 200, remain indexable and keep full product content.
• Structured data availability matches visible stock and updates automatically.
• Discontinued items follow an explicit redirect or 404/410 rule.
• Notify-me captures contact, variant, channel and consent text.
• Email and WhatsApp are separate, unticked choices.
• Every message has an easy stop route; suppression is global.
• Alert rule is written down: threshold, order, batch size, one send per request.
• Stock source of truth is defined and synced.
• Widget scripts load only where needed; INP checked on mobile.
• Requests are deleted after sending or after a stated period.

Working with Govindani Infotech on notify-me and wishlist features

Govindani Infotech is a Pune-based web development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009. We build websites, e-commerce stores, CRM systems and WhatsApp integrations. For a store that keeps running out of its best sellers, our usual starting point is a short review of how stock status, structured data and sold-out pages behave today, followed by a decision on app, plugin or custom build. If you want that review, or a quotation for notify-me, wishlist or WhatsApp alert work, message us on WhatsApp or use the contact page. You can read more about our e-commerce services and WhatsApp flow work.

For what to do with products that are not coming back, see our guide to out-of-stock, discontinued and deleted product pages.

Frequently Asked Questions

Should I delete or 404 an out-of-stock product page?

Not if the product is coming back. Keep the URL live with a 200 status, mark the offer as out of stock and keep the product content. Use a 301 to an equivalent product, or a 404 or 410, only when an item is permanently gone and the page has no further purpose.

Does an out-of-stock page hurt SEO?

It can lose visibility if it reads as an empty or error-like page. Reporting on a Google Office Hours answer suggests Google may treat thin unavailable pages as soft 404s, though the impact was described as theoretical. Keeping the description, images, reviews and alternatives on the page is the safest approach.

Which availability value should I use in Product schema?

Google lists values including InStock, OutOfStock, BackOrder, PreOrder, SoldOut and Discontinued, and says you must not specify more than one. Use OutOfStock for a temporary gap, BackOrder when you accept orders for later fulfilment, and Discontinued for items that will not return.

Do I need consent to send back-in-stock alerts on WhatsApp?

Yes. Meta's opt-in documentation says a business must clearly name itself, get opt-in permission, state what the person is opting in to and honour opt-outs. A notify-me form with explicit, unticked WhatsApp consent text satisfies that approach, and you should store a record of it.

Should I use an app or build notify-me myself?

For most small and mid-sized stores an app is quicker, but check its script weight, data storage and current pricing. Build custom when alerts, wishlists and customer records need to live in your own CRM, or when the catalogue and rules are complex.

Sources: Google Search Central: Merchant listing structured data, Google Search Central: Product structured data, Google Search Central: Ecommerce URL structure, Google Search Central: HTTP and network errors (soft 404), Search Engine Journal: Out-of-stock products and search visibility, Meta for Developers: WhatsApp getting opt-in, web.dev: Optimize Interaction to Next Paint, Shopify Help Center: Inventory, Shopify App Store: Back In Stock Restock Alerts, EY: DPDP Rules, 2025