How to Set Up WooCommerce Shipping Zones for Local Delivery

A customer down the street wants delivery. Your checkout says their address isn’t eligible. That small mismatch can stop a sale before you even know it happened.

Local delivery starts with a clear service area. WooCommerce shipping zones let you define that area, then show a delivery rate to customers whose addresses match it. Once the boundaries are right, the setup is straightforward.

Key Takeaways

Use a shipping zone to define where you deliver, then add Flat Rate or Free Shipping as the delivery method.
Put narrow local zones above broader zones. WooCommerce uses the first zone that matches a customer’s address.
Test addresses inside, outside, and at the edge of your service area before accepting orders.
Local Pickup is a separate choice. Adding it won’t arrange delivery to a customer’s door.

Plan WooCommerce Shipping Zones Around Your Delivery Area

Start with the area your team can reliably serve. A postcode on a map may look close, but the route could take longer than expected. Check your actual delivery capacity before promising coverage at checkout.

A parcel at the center of map zones connected by copper routes.

Choose boundaries you can maintain

WooCommerce can define zones by country, state, or province, with optional postcode limits. For a neighborhood service, postcodes are often more useful than a statewide rule.

Say your store delivers to selected ZIP codes in California. Choose California as the region, then limit the zone to the ZIP codes you serve. ZIP 90210 is one possible test address, but include it only if you can fulfill orders there.

Keep your delivery schedule beside this list. A checkout rate tells customers where delivery is available; it doesn’t tell your staff when to pack and send an order.

Decide what happens outside the area

You may also ship nationally or offer pickup. Decide which option an address outside your local area should see before you build the zones.

A local delivery zone controls eligibility at checkout. It doesn’t calculate driving distance or assign a driver.

If routes change, update the postcode list before you promote delivery to a new neighborhood. That keeps the promise on your product pages aligned with the options at checkout.

Create a Local Delivery Zone in WooCommerce

Ready to build it? Open WooCommerce > Settings > Shipping > Shipping zones in your WordPress dashboard. WooCommerce’s shipping-zone setup guide shows the same settings if your screen looks different after an update.

Add a name your team understands

Select Add zone and enter a clear zone name, such as “Local Delivery.” If you charge different amounts across service areas, names like “Nearby Delivery” and “Outer Delivery” make the list easier to manage.

The zone name is mainly for your store administration. The shipping method’s title is what customers see at checkout, so you can make that more customer-friendly later.

Select the zone region next. Don’t choose a whole country for neighborhood delivery unless you also set postcode restrictions. A broad region without limits could offer your local rate much farther away than intended.

Limit the zone to eligible postcodes

Use the zone’s postcode restriction field to enter the postcodes you serve, then save your changes. Double-check every entry against your delivery map or route list. A missing postcode can reject a nearby customer; an extra one can create an order your team can’t deliver.

Need different prices for different neighborhoods? Create separate zones rather than trying to make one basic flat rate cover every route. You can set a method and price for each zone.

At this point, you’ve defined where delivery applies. You still need a shipping method. Without one, the matching customer won’t have a local delivery rate to choose.

Add the Delivery Rate Customers Will See

WooCommerce includes Flat Rate, Free Shipping, and Local Pickup as core shipping methods. There isn’t a separate core method called “Local Delivery.” For delivery to an address, add Flat Rate or Free Shipping to your local zone.

Charge a flat delivery fee

Open the new zone and select Add shipping method, then choose Flat Rate. Edit the method to enter your delivery cost and change its customer-facing title to something clear, such as “Local Delivery.”

Choose a fee your routes can support. If outer neighborhoods cost more to serve, place them in their own zone with their own flat rate. Review the amount when fuel costs, order volume, or delivery staffing changes.

Check any shipping-class settings if your store uses them. A heavy item may cost more to deliver than a small bag, and you don’t want a rate meant for everyday orders applied without review.

Offer free delivery when it makes sense

Select Free Shipping instead if you want eligible local customers to pay nothing for delivery. WooCommerce can also make free shipping conditional, such as requiring a minimum order amount or an eligible coupon.

If you add both Flat Rate and Free Shipping to the zone, test what shoppers see when they qualify for free delivery and when they don’t. Don’t assume the paid option disappears.

Save the method settings and confirm the method is active. One small switch can be the difference between a usable checkout and “no shipping options available.”

Put Overlapping Zones in the Right Order

Zone order matters. WooCommerce matches a customer’s address to the first eligible zone in the list, then uses that zone’s methods. It won’t collect methods from every matching zone.

For example, a California local-delivery zone limited to selected ZIP codes may overlap a broader California shipping zone. Place the local zone above the statewide one. Otherwise, a customer in your delivery area may see the broader shipping rate instead.

Keep your remaining shipping zones below the local ones, moving from narrower coverage to broader coverage. Check the Rest of the World zone too. Its available methods determine what happens when an address matches none of your named zones.

If you’re unsure which zone won, use an actual checkout address. The rate shown to a shopper is a better test than a zone list that merely looks right.

Test Local Delivery Like a Customer

Settings can look perfect in the dashboard and still surprise you at checkout. Run tests before announcing delivery on your homepage or product pages.

A cardboard parcel, fresh produce, and a paper bag on a shop counter by a window.

Try addresses on both sides of the boundary

Open a private browser window, add a deliverable product to the cart, and enter an address inside your local zone. Confirm that the method name and price are correct.

Next, test a nearby address outside the covered postcodes. It should show your intended alternative, such as standard shipping, or no shipping method if you don’t serve that address. Test a boundary postcode as well. That’s where small entry mistakes tend to show up.

Complete a controlled test order if you can. Check the shipping line, payment record, order notes, and confirmation email. Then confirm your staff can see what they need to prepare the delivery. Repeat on a phone, where many customers will place their orders.

Keep pickup separate from delivery

Pickup means the customer comes to your location; delivery means you take the order to theirs. WooCommerce’s Local Pickup documentation covers the zone-based pickup method.

If you use the Checkout Block, its Local Pickup settings work separately from shipping zones and can offer pickup regardless of the customer’s address. Check which pickup experience your store uses before assuming your local delivery boundary also limits pickup.

Fix Missing or Incorrect Delivery Options

If local delivery doesn’t appear, start with the address. Does its country, state, and postcode match the zone? Then check whether the zone has an active Flat Rate or Free Shipping method.

If the wrong price appears, review the order of your zones. A broader zone above your local one can catch the address first. Also check whether a free-shipping condition or coupon changed the options shown.

Still stuck? Reproduce the issue in a private window with a simple cart. Try another postcode in the same zone to narrow down the cause. If the shipping method appears but the cart resets or checkout stalls, treat that as a separate checkout problem. Our guide to WooCommerce cart session problems can help you check that path.

Make one change at a time and rerun the same test. Changing zones, plugins, and cache settings together makes the cause much harder to find.

Give Your Store a Reliable Hosting Base

Local delivery brings more moving parts to checkout: customer addresses, live shipping choices, and orders your team needs to fulfill promptly. Your hosting won’t set the right postcodes for you, but a slow or unstable store can make a good setup feel broken.

We recommend starting with our WooCommerce hosting launch checklist before you open delivery to more customers. Check backups, SSL, available resources, and a safe place to test updates.

If you’d rather spend your time on products and routes, our WordPress hosting plans give you setup tools, backup protection, security features, and support. Check the features of the plan you choose, then give your checkout a full test before launch.

Frequently Asked Questions

Can WooCommerce limit local delivery by postcode?

Yes. Create a shipping zone for the relevant region and add postcode limits. Then attach Flat Rate or Free Shipping to that zone. The postcode limits decide which customer addresses match; the shipping method supplies the rate.

Does WooCommerce include a Local Delivery method?

WooCommerce core includes Flat Rate, Free Shipping, and Local Pickup. For local delivery, use a delivery-area zone with Flat Rate or Free Shipping. More advanced needs, such as delivery time slots or route-based pricing, require additional tools.

Why do local customers see a different shipping rate?

Their address may match a broader zone placed above your local zone. Check the zone order, postcode entries, and active methods. Test the exact address in checkout after each change.

Can customers choose pickup and delivery?

Yes, if you configure both options. Check how pickup is set up in your store, especially if you use the Checkout Block. Pickup and delivery have different handoff steps, so their checkout names should make the choice obvious.

Make Local Delivery Easy to Buy

A nearby customer should never have to guess whether you deliver to them. Define the right postcodes, attach a clear rate, and test both sides of the boundary.

Start small and verify the full order path. You can expand the service area once checkout and fulfillment work reliably for the customers you already serve.

Submit a Comment Cancel reply

What's New?

UncategorizedWooCommerce Backorders: How to Sell Without OversellingA product sells out, but more stock is on the way. Do you stop taking orders or keep the sale moving? WooCommerce backorders let customers buy while inventory is below zero, but the default setting won’t stop you accepting more orders than you can fill. We can make backorders work with a clear fulfillment limit, accurate stock counts, and an honest delivery message. First, let’s separate what WooCommerce tracks from what your supplier can deliver. How WooCommerce backorders affect stock WooCommerce can continue accepting orders after a tracked product reaches zero. That helps when a restock is confirmed and customers don’t mind waiting. It also creates a risk: allowing backorders doesn’t set a ceiling on how many you can accept. A negative stock count shows the gap between orders and available units. It doesn’t tell you whether incoming stock will cover that gap. We treat supplier-confirmed quantities and existing commitments as the real limit. This distinction matters most during a promotion or a delayed shipment. If demand moves faster than your team can review orders, a product-level backorder setting alone leaves the door open. You need a way to stop new commitments when confirmed supply runs out. Enable WooCommerce backorders on the right product Start with one product, not your whole catalog. We recommend testing a single item whose next shipment and delivery window you can verify. Turn on stock tracking first In WordPress, go to WooCommerce > Settings > Products > Inventory and enable stock management. WooCommerce’s product inventory settings also cover hold-stock timing, notification thresholds, and backorder emails. Those controls do different jobs, so leave unrelated settings alone while you establish the right stock count. Next, open Products, edit the item, and find Product data > Inventory. Enable Manage stock, then enter the quantity you physically have available. For a variable product, check the purchased variation as well. A size or color with its own tracked inventory needs the correct count and backorder setting. If tracking was previously off, don’t assume enabling it will fix earlier orders. Reconcile recent sales against actual inventory before saving a new quantity. Choose how customers can order The product’s backorder choices are Do not allow, Allow, and Allow, but notify customer. Choose the notification option when you want shoppers told that their item is on backorder. Save the product, then check its storefront page and checkout on both desktop and mobile. We prefer the customer-notification option when delivery won’t be immediate. Still, the setting is only permission to order. It isn’t a promise about dispatch dates, and it doesn’t limit the size of your backorder queue. Those decisions need separate controls. Put a firm limit on what you can fulfill Here’s the part that protects your customers. Decide how many units you can commit before you leave backorders open. Count confirmed supply, then subtract commitments Use a supplier-confirmed incoming quantity, not a hopeful restock date. Subtract units already promised to customers, along with any stock allocated to another sales channel. The remainder is what you can safely offer to new buyers. Keep one record for each SKU or variation. A single product-level count can hide a shortage if one color sells out faster than the others. If a supplier reduces its allocation, update your selling limit promptly and contact any customers whose dates may change. Add a cap when manual checks aren’t fast enough Core WooCommerce doesn’t provide a documented maximum-backorders field. If you only review orders periodically, more purchases can arrive before you switch the product back to Do not allow. For a store that needs an automatic ceiling, evaluate an extension and test its behavior with your checkout. The FMA Pre Order and Backorder settings include a Maximum Quantity option. Check whether its limit applies to the product, each variation, or the backorder quantity you intend to control before relying on it. Don’t confuse Sold Individually with a queue limit. It restricts a customer to one of that product per order; it doesn’t stop another customer placing an order. Give shoppers a delivery message they can trust A backorder notice tells customers they’ll wait. They still need enough detail to decide whether that wait works for them. Put the timeframe where buyers will see it Show your current dispatch estimate on the product page and repeat it in the order confirmation when your setup allows. If the supplier hasn’t confirmed a date, say so instead of presenting a guess as a guarantee. Make your cancellation or refund route easy to find, too. We’d rather lose one uncertain sale than create a support thread full of missed promises. When a delivery estimate changes, contact affected customers. Updating the product page helps new buyers, but it doesn’t inform people who already ordered. Keep staff alerts separate from customer notices The Allow, but notify customer choice affects what the buyer sees. WooCommerce’s backorder notification setting sends a stock-related email when an order creates a backorder, provided stock management is enabled and the product allows them. It doesn’t replace your customer delivery message. Low-stock and out-of-stock thresholds have different purposes. One alerts you as inventory runs down; the other affects when WooCommerce marks stock out of stock. Neither is a total backorder cap. Check each setting against the problem you’re trying to solve rather than changing them together. Watch orders, payments, and stock as one trail A sale isn’t finished when a customer clicks the checkout button. Payment status and stock records need to agree, particularly when demand is high. Know what the order status means Hold stock (minutes) applies to unpaid orders in Pending payment status. It temporarily holds stock while payment is unfinished; it doesn’t cap the number of backorders you’ll accept. WooCommerce recommends checking this setting when pending orders tie up inventory. An On hold order is different: payment confirmation is still needed, and stock has been reduced. When a managed-stock order is Cancelled, its stock is returned. We check the WooCommerce inventory settings before changing hold times, especially if a payment method takes longer to confirm. Investigate a mismatch before editing quantities Pick one order and note its ID, status, item, variation, and quantity. Compare the order notes with the saved stock number in the product editor. If payment succeeded but the order hasn’t updated, check the payment gateway record and integration before adjusting inventory. If the editor has the correct count but shoppers see an old number, inspect the cache. Purge the product page where needed and check again in a private window. Cart and checkout pages should show each customer’s live session, not a cached copy. Our checkout troubleshooting guide helps when the buying path itself is failing. Test backorders before opening the queue One successful test tells you less than you might think. We run through the buying path a customer will use and confirm what happened afterward. Place controlled test orders Use your payment gateway’s test mode where available. Test a purchase while stock remains, then a purchase that crosses into backorder territory. Confirm the product message, checkout details, order status, stock change, and emails. Review the order notes rather than relying only on what the product page displayed. If you sell variations, test the exact variation you’ll offer on backorder. Try guest checkout if it’s enabled, plus the payment methods customers use most. A controlled failed payment is useful too: it shows whether an unpaid order holds stock as expected. Check the limit and the live storefront If you’ve installed a quantity-cap extension, test the last permitted unit and the next attempted purchase. Confirm that checkout rejects the excess rather than merely displaying a warning. Repeat after any major plugin or theme change. We use staging for changes like these, with a backup available before touching the live store. Our WooCommerce hosting launch checklist covers staging and restore checks. Keep live orders out of any staging database restore, then watch real orders closely after launch. Give the store a dependable hosting foundation Backorder controls depend on a checkout that can complete orders and save stock changes. Hosting won’t create a quantity cap, but slow requests, failed checkouts, and stale pages can make a careful inventory plan harder to manage. Our WordPress hosting plans offer tools such as backups, staging, SSL, malware scanning, and support; check the features included in the plan you choose. That’s a practical fit if you want room to test a backorder extension, check a checkout issue, and restore the site when an update goes wrong. During a busy sale, watch for a different symptom: the product editor shows the right quantity, but the storefront lags behind. Ask your host to review caching and server logs before changing stock by hand. Accurate counts matter most when orders arrive quickly. Key Takeaways Enable stock management globally and on each product or variation before allowing backorders. Set your selling limit against confirmed incoming units and orders already promised. Core WooCommerce won’t cap the queue for you. Tell customers what the wait means, then test stock changes, payment outcomes, and any extension limit at checkout. Frequently Asked Questions Can WooCommerce backorders stop automatically at a set quantity? Core WooCommerce lets tracked stock go below zero when backorders are allowed, but it doesn’t provide a documented maximum-backorders field. Use a tested extension with the limit you need, or close backorders manually before confirmed supply is fully committed. Manual checks need extra attention when orders arrive quickly. Why can customers still buy a product with zero stock? Open the product’s inventory settings and check whether backorders are allowed. Also confirm stock management is enabled globally and for that product or variation. A low-stock email doesn’t make an item unavailable, and an out-of-stock threshold isn’t a limit on accepted backorders. Will enabling stock management fix previous orders? No. Reconcile older orders against physical inventory first. Check their statuses and order notes, then enter a verified quantity. Turning on tracking gives WooCommerce a starting point for future stock changes; it doesn’t automatically reconstruct every earlier sale. Keep Every Backorder Within Reach WooCommerce backorders can keep a sale moving while stock is on its way. The setting works best when we pair it with confirmed supply, a clear customer promise, and checkout tests that prove our limit holds. Start with one product and one verified shipment. Open the queue only for orders you can fulfill. [...]
Read more...
UncategorizedHow to Set Up WooCommerce Shipping Zones for Local DeliveryA customer down the street wants delivery. Your checkout says their address isn’t eligible. That small mismatch can stop a sale before you even know it happened. Local delivery starts with a clear service area. WooCommerce shipping zones let you define that area, then show a delivery rate to customers whose addresses match it. Once the boundaries are right, the setup is straightforward. Key Takeaways Use a shipping zone to define where you deliver, then add Flat Rate or Free Shipping as the delivery method. Put narrow local zones above broader zones. WooCommerce uses the first zone that matches a customer’s address. Test addresses inside, outside, and at the edge of your service area before accepting orders. Local Pickup is a separate choice. Adding it won’t arrange delivery to a customer’s door. Plan WooCommerce Shipping Zones Around Your Delivery Area Start with the area your team can reliably serve. A postcode on a map may look close, but the route could take longer than expected. Check your actual delivery capacity before promising coverage at checkout. Choose boundaries you can maintain WooCommerce can define zones by country, state, or province, with optional postcode limits. For a neighborhood service, postcodes are often more useful than a statewide rule. Say your store delivers to selected ZIP codes in California. Choose California as the region, then limit the zone to the ZIP codes you serve. ZIP 90210 is one possible test address, but include it only if you can fulfill orders there. Keep your delivery schedule beside this list. A checkout rate tells customers where delivery is available; it doesn’t tell your staff when to pack and send an order. Decide what happens outside the area You may also ship nationally or offer pickup. Decide which option an address outside your local area should see before you build the zones. A local delivery zone controls eligibility at checkout. It doesn’t calculate driving distance or assign a driver. If routes change, update the postcode list before you promote delivery to a new neighborhood. That keeps the promise on your product pages aligned with the options at checkout. Create a Local Delivery Zone in WooCommerce Ready to build it? Open WooCommerce > Settings > Shipping > Shipping zones in your WordPress dashboard. WooCommerce’s shipping-zone setup guide shows the same settings if your screen looks different after an update. Add a name your team understands Select Add zone and enter a clear zone name, such as “Local Delivery.” If you charge different amounts across service areas, names like “Nearby Delivery” and “Outer Delivery” make the list easier to manage. The zone name is mainly for your store administration. The shipping method’s title is what customers see at checkout, so you can make that more customer-friendly later. Select the zone region next. Don’t choose a whole country for neighborhood delivery unless you also set postcode restrictions. A broad region without limits could offer your local rate much farther away than intended. Limit the zone to eligible postcodes Use the zone’s postcode restriction field to enter the postcodes you serve, then save your changes. Double-check every entry against your delivery map or route list. A missing postcode can reject a nearby customer; an extra one can create an order your team can’t deliver. Need different prices for different neighborhoods? Create separate zones rather than trying to make one basic flat rate cover every route. You can set a method and price for each zone. At this point, you’ve defined where delivery applies. You still need a shipping method. Without one, the matching customer won’t have a local delivery rate to choose. Add the Delivery Rate Customers Will See WooCommerce includes Flat Rate, Free Shipping, and Local Pickup as core shipping methods. There isn’t a separate core method called “Local Delivery.” For delivery to an address, add Flat Rate or Free Shipping to your local zone. Charge a flat delivery fee Open the new zone and select Add shipping method, then choose Flat Rate. Edit the method to enter your delivery cost and change its customer-facing title to something clear, such as “Local Delivery.” Choose a fee your routes can support. If outer neighborhoods cost more to serve, place them in their own zone with their own flat rate. Review the amount when fuel costs, order volume, or delivery staffing changes. Check any shipping-class settings if your store uses them. A heavy item may cost more to deliver than a small bag, and you don’t want a rate meant for everyday orders applied without review. Offer free delivery when it makes sense Select Free Shipping instead if you want eligible local customers to pay nothing for delivery. WooCommerce can also make free shipping conditional, such as requiring a minimum order amount or an eligible coupon. If you add both Flat Rate and Free Shipping to the zone, test what shoppers see when they qualify for free delivery and when they don’t. Don’t assume the paid option disappears. Save the method settings and confirm the method is active. One small switch can be the difference between a usable checkout and “no shipping options available.” Put Overlapping Zones in the Right Order Zone order matters. WooCommerce matches a customer’s address to the first eligible zone in the list, then uses that zone’s methods. It won’t collect methods from every matching zone. For example, a California local-delivery zone limited to selected ZIP codes may overlap a broader California shipping zone. Place the local zone above the statewide one. Otherwise, a customer in your delivery area may see the broader shipping rate instead. Keep your remaining shipping zones below the local ones, moving from narrower coverage to broader coverage. Check the Rest of the World zone too. Its available methods determine what happens when an address matches none of your named zones. If you’re unsure which zone won, use an actual checkout address. The rate shown to a shopper is a better test than a zone list that merely looks right. Test Local Delivery Like a Customer Settings can look perfect in the dashboard and still surprise you at checkout. Run tests before announcing delivery on your homepage or product pages. Try addresses on both sides of the boundary Open a private browser window, add a deliverable product to the cart, and enter an address inside your local zone. Confirm that the method name and price are correct. Next, test a nearby address outside the covered postcodes. It should show your intended alternative, such as standard shipping, or no shipping method if you don’t serve that address. Test a boundary postcode as well. That’s where small entry mistakes tend to show up. Complete a controlled test order if you can. Check the shipping line, payment record, order notes, and confirmation email. Then confirm your staff can see what they need to prepare the delivery. Repeat on a phone, where many customers will place their orders. Keep pickup separate from delivery Pickup means the customer comes to your location; delivery means you take the order to theirs. WooCommerce’s Local Pickup documentation covers the zone-based pickup method. If you use the Checkout Block, its Local Pickup settings work separately from shipping zones and can offer pickup regardless of the customer’s address. Check which pickup experience your store uses before assuming your local delivery boundary also limits pickup. Fix Missing or Incorrect Delivery Options If local delivery doesn’t appear, start with the address. Does its country, state, and postcode match the zone? Then check whether the zone has an active Flat Rate or Free Shipping method. If the wrong price appears, review the order of your zones. A broader zone above your local one can catch the address first. Also check whether a free-shipping condition or coupon changed the options shown. Still stuck? Reproduce the issue in a private window with a simple cart. Try another postcode in the same zone to narrow down the cause. If the shipping method appears but the cart resets or checkout stalls, treat that as a separate checkout problem. Our guide to WooCommerce cart session problems can help you check that path. Make one change at a time and rerun the same test. Changing zones, plugins, and cache settings together makes the cause much harder to find. Give Your Store a Reliable Hosting Base Local delivery brings more moving parts to checkout: customer addresses, live shipping choices, and orders your team needs to fulfill promptly. Your hosting won’t set the right postcodes for you, but a slow or unstable store can make a good setup feel broken. We recommend starting with our WooCommerce hosting launch checklist before you open delivery to more customers. Check backups, SSL, available resources, and a safe place to test updates. If you’d rather spend your time on products and routes, our WordPress hosting plans give you setup tools, backup protection, security features, and support. Check the features of the plan you choose, then give your checkout a full test before launch. Frequently Asked Questions Can WooCommerce limit local delivery by postcode? Yes. Create a shipping zone for the relevant region and add postcode limits. Then attach Flat Rate or Free Shipping to that zone. The postcode limits decide which customer addresses match; the shipping method supplies the rate. Does WooCommerce include a Local Delivery method? WooCommerce core includes Flat Rate, Free Shipping, and Local Pickup. For local delivery, use a delivery-area zone with Flat Rate or Free Shipping. More advanced needs, such as delivery time slots or route-based pricing, require additional tools. Why do local customers see a different shipping rate? Their address may match a broader zone placed above your local zone. Check the zone order, postcode entries, and active methods. Test the exact address in checkout after each change. Can customers choose pickup and delivery? Yes, if you configure both options. Check how pickup is set up in your store, especially if you use the Checkout Block. Pickup and delivery have different handoff steps, so their checkout names should make the choice obvious. Make Local Delivery Easy to Buy A nearby customer should never have to guess whether you deliver to them. Define the right postcodes, attach a clear rate, and test both sides of the boundary. Start small and verify the full order path. You can expand the service area once checkout and fulfillment work reliably for the customers you already serve. [...]
Read more...
WordPressWooCommerce Stock Not Updating After Orders? Find the BreakYou make a sale, open the product, and see the same stock number. If you’re seeing WooCommerce stock not updating after orders, changing the quantity by hand could hide the cause or leave you with more stock listed than you can ship. Start by checking the saved stock quantities, then review stock settings and order behavior. If those look right, investigate integrations and what shoppers see. WooCommerce stock not updating? Check the saved quantity first A product page can show an old number even after WooCommerce has recorded the sale. Before touching settings, pick one affected order and one product in it. Compare the order with the product editor In WordPress, open WooCommerce > Orders and find the order. Note its order status, the item purchased, its quantity, and any variation, such as size or color. Next, open that item under Products and check its saved stock quantities. If the saved number fell but the storefront didn’t change, investigate caching. If it stayed put, move on to stock tracking settings and the payment flow. Check the order notes too. They can show status changes and stock reduction, giving you a better trail than a screenshot of the product page. WooCommerce’s order troubleshooting guidance recommends reviewing those details when stock and orders disagree. Use one order as your reference point Write down the expected quantity before making a change. If you had eight units and sold two, you expect six, unless another order, refund, or staff edit changed the count. Change one thing at a time. Keep the order ID handy, then check that same product after each fix. A random test purchase won’t tell you much if it uses another variation or payment method. Turn on stock management where it counts WooCommerce needs permission for stock tracking at both the store and product levels. Entered stock quantities won’t help if inventory management is off. Check the store-wide and product settings Go to WooCommerce > Settings > Products > Inventory and enable the store-wide Manage stock setting. Then open the affected product and check its Inventory settings. Confirm Manage stock is enabled, the quantity is correct, and the backorder setting matches what you intend to sell. If stock management was disabled, save the settings and test with a new order. Don’t assume turning it on will correct older orders. Reconcile their quantities against actual inventory first. WooCommerce’s product inventory settings also include hold-stock timing and notification thresholds. Those controls solve different problems, so resist changing them all at once. Separate alerts from product availability A low-stock threshold tells you when inventory is running down. The out-of-stock threshold controls when WooCommerce marks an item out of stock. If you’re getting an alert but the product remains available, check the stock threshold you’ve set. Backorders matter too. An item may still accept purchases when its count reaches zero if you’ve allowed backorders. Review the product’s inventory levels, stock status, and backorder choice together before treating the storefront as broken. Follow the payment and order status If you’re troubleshooting WooCommerce stock not updating after an order, compare the customer’s payment claim with WooCommerce’s recorded result. The payment gateway, webhooks, and order status changes can all affect the stock quantities shown in the dashboard. Confirm the gateway result before changing an order Open the order notes, then compare them with the transaction in your gateway dashboard. With a gateway such as Stripe, look for the transaction ID and confirm whether payment was authorized, captured, or failed. If the gateway shows success but WooCommerce still shows Pending payment, check the gateway’s webhook delivery and configuration. Don’t change the order status just because it looks stuck. Verify the payment first, or you could create a second problem while leaving the original integration fault untouched. A paid order doesn’t have to reach Completed for stock reduction to occur. A move to the processing status can be enough. WooCommerce handles stock according to its payment and status events, so the order notes and transaction record matter more than one status label. Its order status documentation explains the distinctions. Treat pending and failed orders with care The Hold stock timer applies to unpaid Pending payment orders. When the timer expires, WooCommerce can cancel the order and release held stock. It isn’t a timer for orders marked On hold. Also check whether stock was reduced and later returned. In WooCommerce 11.0, an order moving to Failed restores stock that was previously reduced. That can make a quantity appear unchanged if you only compare the start and end numbers. Before changing anything, check whether staff already shipped the item or adjusted its stock. Check the exact variation the customer bought Variable products add another place for the count to hide. You may be looking at the main listing while WooCommerce tracks each size or color separately. Find out where inventory is tracked Open the variable product and inspect its Variations. If each variation has its own stock management enabled, check the stock quantities for the product variation named in the order. The parent product’s inventory field isn’t the number to compare in that setup. For example, a sale of a medium blue shirt should reduce that variation’s quantity when it manages its own stock. The quantity for a small blue shirt should stay the same. WooCommerce’s variable product guidance explains variation-level inventory and its controls. Check every variation’s rules An imported or newly added variation may have a different stock setting from its siblings. Inspect the affected variation’s quantity, stock status, and backorder setting, then save it. If several variations draw from one shared pool of physical stock, decide how you’ll track that pool on the parent product before editing numbers. Otherwise, you can count the same items more than once and invite overselling. Rule out a stale storefront display If WooCommerce stock not updating seems likely, but the product editor shows the correct reduced quantity, focus on page delivery. Caching issues can hide a fresh update; they don’t prove stock reduction failed. Before checking caches, look for conflicting plugins or custom code that could interrupt stock tracking. Back up your site first, then test changes on staging when possible. Check each cache layer Purge the relevant product page from your WordPress cache plugin, host cache, and CDN. Then check it in a private browser window. If the fresh page shows the right number, review how and when that page’s cache is cleared after a sale. Keep customer-specific pages live. WooCommerce’s caching guidance for stores says to exclude Cart, Checkout, and My Account from page caching. Check for caching issues at every layer, not only in a plugin. A Cloudflare rule or server cache can still serve stale content after you clear WP Rocket or LiteSpeed Cache. Look for delays beyond the page cache If stock quantities update late rather than immediately, check whether the integration supports real-time sync. Note the time and check for slow requests, gateway delays, or failed background work. Your host can help review server logs around the affected order. Hosting needs the right cache controls as well as enough resources for checkout traffic. Our WooCommerce hosting checklist covers the store pages that need special handling. If inventory syncing relies on background jobs, failed WooCommerce scheduled actions are worth checking too. Correct the numbers without creating a new mismatch Once you’ve found the cause, take a full site backup, then reconcile WooCommerce stock quantities with what you can ship. Check recent orders, refunds, manual edits, and any external inventory syncing before changing inventory levels or risking overselling. For a few products, edit each quantity in the product or variation inventory settings. For a larger catalog, use a careful bulk update with a CSV import: Export the current products and save a backup before changing inventory. Update existing products only, changing the stock fields you intend to correct. Match each product ID or SKU to the right item. Test the CSV import on a staging copy, especially if you sell variations. Check that each row maps to the intended product. Verify sample quantities and a test order on staging, then run the CSV import on the live store during a quiet period. Check sample stock levels afterward. A CSV made yesterday can overwrite sales made today, so reconcile recent orders immediately before the live import. Keep the original export in case you need to trace a mistake. A bulk correction fixes the count, but not the setting or integration that caused the mismatch. Direct database edits are an advanced last resort, not a routine fix. Keep the next order from causing the same headache After a successful test, monitor the next real orders through checkout, payment, and fulfillment. Compare order notes with product stock levels and record when a discrepancy appears. That gives you an early warning before a busy sales day magnifies it. If two shoppers can buy the last unit, check stock management, backorders, and pending-payment holds. Stores with multiple sales channels also need a clear source of truth for inventory syncing. When systems write competing values, stock tracking can drift. A bulk update may align them temporarily, but it won’t provide real-time sync or prevent overselling. Repeated timeouts or cache problems deserve a hosting review. ZADiC’s WordPress hosting with backups and support gives you a stronger base and people to contact when checkout trouble needs investigation. Hosting can’t correct a disabled product setting, but reliable resources and help make the next issue easier to catch. Key Takeaways Start with the saved product quantity. If WooCommerce stock not updating, check whether stock quantities changed or the storefront still shows an old page or an out of stock message. Check global and product settings to confirm you can manage stock, then trace the order status and payment record. For variable products, inspect the purchased variation and its stock status. Before bulk corrections, back up, test, and reconcile recent sales to prevent overselling. Frequently Asked Questions Why hasn’t stock reduced after a paid order? If you’re dealing with WooCommerce stock not updating after a paid order, verify payment in the payment gateway dashboard and compare it with the WooCommerce order notes. If payment succeeded but the order wasn’t updated, investigate the gateway’s webhook. Then check that stock management is enabled globally and on the product or purchased variation. Don’t force a status change without confirming payment. Why does an out-of-stock product still accept orders? Check its saved stock quantities, out of stock threshold, and backorder setting. If backorders are allowed, customers may still buy it while it’s marked out of stock. If the editor shows it as unavailable but the product page says otherwise, clear the page cache and test again. Can slow hosting cause stock to show the wrong number? A slow server can delay requests, while a cache can show visitors older stock levels on a product page. Neither is proof that WooCommerce saved the wrong quantity. Compare the product editor with the storefront first. If updates happen late or checkout requests fail under traffic, ask your host to review logs for the affected order. Fix the Break Before Editing the Count When WooCommerce stock not updating, the unchanged number after a sale is a clue, not a diagnosis. Find the saved quantity, trace the order, and check the exact product or variation before adjusting stock quantities. That short trail tells you whether to fix a setting, a payment update, or a stale page. Accurate inventory levels start with finding the break, then confirming the next order works as expected. [...]
Read more...
WordPressHow to Disable WordPress Pingbacks Without Losing CommentsYour comment section should welcome real conversations, not a pile of automated link notices. The good news is you can disable WordPress pingbacks without turning off normal visitor comments. It takes a few minutes to handle the right settings, clean up older posts, and decide whether XML-RPC needs tighter protection. Start with the simple fix, then add security layers that fit how your site runs. Key Takeaways You can disable WordPress pingbacks without turning off regular visitor comments. Turn off pingbacks and trackbacks in Settings > Discussion, then bulk-edit older posts and pages separately. Keep internal links in place by filtering self-pingbacks rather than removing useful links. Disabling pingbacks does not block XML-RPC. Check whether Jetpack, the WordPress mobile app, or remote publishing tools rely on it before restricting xmlrpc.php. Test comments, internal linking, connected tools, and your recovery plan after making changes. What Pingbacks Do, and Why Comments Stay Separate Pingbacks are automated notifications sent when one website links to another. WordPress can receive, approve, and display them alongside comments. They aren’t the same as comments. WordPress keeps these settings separate, so you can close the door on pingback spam while keeping customer questions, product feedback, and community conversations open. Pingbacks and trackbacks are close, but not identical A trackback is a manual notification. The site owner sends it to tell another site about a linked post. A pingback is automatic. WordPress checks that a link exists before sending the notification, which sounds tidy in theory. In practice, both can fill a moderation queue with noise. The official WordPress explanation of trackbacks and pingbacks breaks down their original purpose. Self-pingbacks are internal-link clutter A self-pingback appears when one post links to another post on the same site. Useful internal linking can make related articles appear as internal notifications. That isn’t a hack. It’s clutter in the moderation workflow, not a reason to remove helpful links. Still, it can make a busy comment section feel messy fast. Why Disable WordPress Pingbacks? Pingbacks were built for a more social version of blogging. Most small business sites don’t need them now, so you can disable WordPress pingbacks without closing your comments. Spam is one reason to turn them off. Security is the bigger one. A pingback request uses the WordPress XML-RPC endpoint, usually found at xmlrpc.php. Attackers can abuse it to send requests through many WordPress sites toward one target. Pingbacks can add noise and risk A flood of pingback spam wastes moderation time. Worse, attackers can use pingback requests in a reflection attack. They can prompt vulnerable sites to request a target URL, creating unwanted traffic that may contribute to DDoS attacks. XML-RPC can also be abused for password guessing during brute-force attacks. Cloudflare documented how system.multicall could pack many login attempts into one request in its report on WordPress brute-force amplification attacks. Turning off pingbacks stops link notifications. For broader WordPress security, review unused XML-RPC functions separately. That protection is a separate decision from disabling pingbacks. Comments do not need to disappear You don’t need to choose between security and engagement. Leave your regular comment setting active, then turn off only pingbacks and trackbacks. That distinction matters for service businesses, stores, and blogs that rely on real questions from real people in the comment section. Disable WordPress Pingbacks in Global Discussion Settings This is the fastest place to start. It applies the rule to new posts you publish after saving the setting. In your WordPress dashboard, go to Settings > Discussion. Look for these two options: “Attempt to notify any blogs linked to from the post” “Allow link notifications from other blogs (pingbacks and trackbacks) on new posts” Uncheck both boxes, then select Save Changes. Keep “Allow people to submit comments on new posts” checked if you still want visitor comments. WordPress lists these as separate discussion options, so changing the pingback setting does not close comments. One important detail: this global change doesn’t update older content. Those posts need their own cleanup. Turn Off Pingbacks on Individual Posts and Pages Need to control one post without changing the whole site? Open that post or page in the WordPress editor. Find the Discussion panel. Depending on your WordPress version and editor setup, it may sit in the right-hand settings sidebar or lower on the edit screen. Uncheck the option that allows pingbacks and trackbacks, but leave the comments option enabled. Then update the post. This is useful for a page that attracts unwanted link notifications, while you still want pingbacks elsewhere. WordPress confirms that the post editor has separate discussion controls for comments and pingbacks. Bulk Edit Existing Posts to Remove Active Pingbacks Older posts are where most site owners get caught. You disable WordPress pingbacks for future content, then old articles keep accepting them. Head to Posts > All Posts. Select the posts you want to update, choose Edit from the Bulk actions menu, and click Apply. In the bulk editor, set Pings to “Do not allow,” then select Update. Repeat the process in Pages > All Pages if your pages also allow pings. On larger sites, work in batches and verify the first batch before moving on. A few dashboard labels may differ by WordPress version. The setting you need always refers to pings, pingbacks, or trackbacks. It does not refer to ordinary comments. Stop self-pingbacks While Keeping Internal Links Internal linking helps visitors find related services, guides, and product pages. Don’t stop linking just to avoid self-pingbacks. You have two clean options. The first is to turn off incoming pingbacks globally, which is simplest when outside pingbacks aren’t useful. The second preserves internal linking while filtering only links that point back to your own domain. For a focused plugin alternative, No Self Ping blocks internal notifications without replacing your comment system. Shield Security PRO provides broader WordPress protection and can complement this targeted approach. Before enabling overlapping notification or security controls, review plugin settings. If Shield Security PRO is active, review its Shield Security PRO settings as well. Use a small code snippet for internal links The displayed PHP code snippet filters self-pingbacks before WordPress sends notifications. Place this code snippet in a custom site plugin or maintained tool such as the WPCode plugin. Avoid editing functions.php directly unless you manage a child theme and have a recovery plan: function zadic_stop_self_pingbacks( &$links ) { $home = get_option( 'home' ); foreach ( $links as $key => $link ) { if ( 0 === strpos( $link, $home ) ) { unset( $links ); } } } add_action( 'pre_ping', 'zadic_stop_self_pingbacks' ); Test this code snippet on a staging site first. Also check that your WordPress Address and Site Address use the same canonical domain. A mismatch between www and non-www versions can let some self-pings slip through. Keep your comment workflow clean Once self-pingbacks stop, review your comment moderation queue and delete old internal notifications. Don’t confuse them with customer comments. A tidy moderation queue means less time sorting junk and more time answering people who may become customers. Preserve useful internal linking so visitors can still discover related content. Block XML-RPC Only When Your Site Doesn’t Need It Disabling pingbacks changes a WordPress setting. It doesn’t block the XML-RPC endpoint. XML-RPC has valid uses. The WordPress mobile app, the Jetpack plugin, and remote publishing tools may depend on it. If you use any of them, blocking the endpoint can break a workflow you rely on. Check what relies on XML-RPC first Before you block anything, test your site and list the tools connected to it. Identify whether xmlrpc.php is used by Jetpack features, mobile publishing, external posting tools, or older integrations. If none depend on XML-RPC, restricting the endpoint removes the path used for pingback requests and multicall login attempts that enable brute-force attacks. It can also reduce reflected traffic involved in some DDoS attacks. Choose the right protection layer On Apache hosting, you can block xmlrpc.php through the site’s .htaccess file with a tested code snippet. Follow cPanel’s XML-RPC blocking instructions rather than pasting random rules from an old forum post. Shield Security PRO can also help manage this choice through its plugin settings. Nginx users need a server level rule, usually added by the hosting provider. A web application firewall can restrict requests to the XML-RPC file, while Shield Security PRO can monitor related activity. Ask your host about the safest server configuration code snippet for your setup. For a WordPress-level option, the filter add_filter( 'xmlrpc_enabled', '__return_false' ); disables XML-RPC methods. You might place this code snippet in functions.php, but a site-specific plugin is safer for maintainability. Shield Security PRO can provide another WordPress-level option when you don’t want to maintain PHP changes. A WordPress filter isn’t equivalent to hosting or firewall protection. Server level blocking is stronger when XML-RPC is genuinely unused, because requests are stopped before WordPress loads. Shield Security PRO is an alternative to manually maintained rules, and its monitoring can help confirm whether a block is safe. Keep a tested code snippet and a recovery plan before changing server settings. Shield Security PRO can help review the change, but layered WordPress security still matters because blocking XML-RPC won’t stop every brute-force attack. Test the Change and Protect Your Recovery Plan After making changes, test a regular comment from a logged-out browser or ask someone you trust to comment. Confirm it reaches moderation or publishes normally under your usual settings. If you use Shield Security PRO, review its relevant status and logs. Test your internal linking by connecting two existing posts. No self-pingbacks should appear. Check Jetpack, the WordPress mobile app, and connected tools if you changed XML-RPC access. Review xmlrpc.php for unintended exposure, but remember this check can’t prove complete protection against brute-force attacks. If you use Shield Security PRO, retest after changing its settings. Before editing .htaccess or a server configuration code snippet, create a full backup. If you’d rather spend your time on the business, our managed WordPress hosting includes automatic backups, security monitoring, staging, and WordPress support in one place. Keep the Conversation, Lose the Noise Pingbacks are optional, and they don’t control your comment section. You can remove automated link notifications while keeping genuine engagement and internal linking intact. Start with Discussion settings, update older posts, then consider XML-RPC protection only after checking your integrations. For broader WordPress protection, Shield Security PRO is an optional security layer, not a requirement. FAQ Will disabling pingbacks turn off WordPress comments? No. Pingbacks, trackbacks, and regular comments use separate controls. Keep the normal comment option checked in Discussion settings and on individual posts where you want visitor feedback. Do global Discussion settings update old posts? No. They apply only to new posts going forward. Use the bulk editor to change ping settings on older posts and pages. Should every WordPress site block xmlrpc.php? Not always. Block it when your site doesn’t use the WordPress mobile app, Jetpack features, or remote publishing tools that require XML-RPC. A WordPress-level filter or code snippet may be better than server-level blocking in some setups. Shield Security PRO is another optional protection method, but test its integrations first. Can self-pingbacks hurt search rankings? Self-pingbacks don’t directly hurt search rankings. They mainly create moderation clutter. Keep your internal links so visitors can find related content, then block the internal notifications instead. [...]
Read more...
WordPressWordPress Heartbeat Settings Without Broken Admin TasksA slow WordPress dashboard can feel like your hosting is letting you down. Sometimes it is. But often, small background requests are stacking up behind the scenes. WordPress Heartbeat settings can reduce server load without turning off the admin features you rely on. The smart move isn’t to disable everything. It’s to identify where Heartbeat is busy, slow it down where it’s safe, and protect autosaves where it matters. Start with proof, then make the smallest change that solves the problem. What the WordPress Heartbeat API Actually Does WordPress introduced the Heartbeat API in version 3.6. It lets a browser check in with the server at intervals, so WordPress can respond to admin events without a full page refresh. How requests reach admin-ajax.php Heartbeat sends AJAX POST requests through admin-ajax.php. Each request uses PHP and server resources, even when the response is small. The official WordPress Heartbeat API documentation describes this as a periodic client-side tick. Depending on the screen and settings, intervals generally fall between 15 and 120 seconds. One request is harmless. A dozen logged-in users, several open editor tabs, and a busy WooCommerce dashboard can create a steady stream of work for your PHP workers. Admin tasks that depend on Heartbeat Heartbeat isn’t random background chatter. It supports useful tasks, including: The post editor’s autosave and post revisions. Post locking, which warns editors when someone else has a page open. Session management and expiration notices. Some plugin notifications and real-time updates. That’s why a full shutdown can create new problems while fixing an old one. Less server load sounds great, until an editor loses an unsaved landing page or collaborative editing stops working. Diagnose Heartbeat Load Before Changing Settings Don’t blame Heartbeat because admin-ajax.php appears in a server report. That file handles plenty of WordPress and plugin activity. Confirm the admin-ajax.php request is actually Heartbeat Open your browser’s developer tools, go to the Network tab, and filter for admin-ajax.php. Look at the request payload or query details. You are looking for action=heartbeat. If it isn’t there, Heartbeat isn’t the request you need to fix. This small check saves time. A page builder, security plugin, or form integration may generate unrelated AJAX calls instead. Query Monitor can also help you inspect plugin and database activity. Match request patterns to server strain Check your hosting control panel for CPU usage, memory, entry processes, and PHP workers. Then compare those numbers with real behavior. Does CPU jump when editors are active? Does the issue happen only during product updates? Does it disappear after everyone logs out? These comparisons help isolate performance issues. A high number of admin-ajax.php requests is not enough evidence. Confirm repeated action=heartbeat requests before changing the setting. We also recommend testing at a quiet time. You need a clear before-and-after picture, not a guess made during a traffic spike. Choose the Smallest Safe Change First The Heartbeat API reference covers the background requests that keep WordPress admin tasks active. A longer request interval is usually safer than disabling Heartbeat outright. It lowers the number of calls while keeping essential work running. Slow it down before shutting it off For many small business sites, a 60-second interval is a sensible starting point for the dashboard. It reduces background requests without making the admin area feel frozen. Only disable heartbeat after testing a longer interval and confirming it isn’t enough. This keeps the change targeted and easier to reverse. The post editor deserves more care. If you publish often, write long pages, or have several people editing content, keep Heartbeat active there. On editor-heavy sites, prioritize autosave and post locking over the smallest possible request count. Intervals from 15 to 120 seconds are common. Stay inside that range unless a plugin’s documentation tells you otherwise. Treat each WordPress area differently Think in three areas: AreaSafe starting pointWhyFrontendDisable or use a long intervalMost visitor-facing pages don’t need Heartbeat.DashboardSet 60 to 120 secondsAdmin checks still work with fewer requests.Post editorKeep enabled, use 30 to 60 secondsAutosave and post locking need regular contact. The takeaway is simple: don’t use one setting everywhere. Public pages, the dashboard, and the post editor have different jobs. Configure WordPress Heartbeat Settings With Plugins A plugin is the easiest route for most site owners. The Heartbeat Control plugin and Perfmatters are reputable options, but the best optimization plugins are easy to maintain and reverse. It also makes rollback simple, and the Heartbeat Control plugin keeps that process accessible when an admin task suddenly stops working. Control Heartbeat in WP Rocket WP Rocket includes Heartbeat controls under Settings > WP Rocket > Heartbeat. Enable the control, then choose whether to reduce activity, disable it, or leave it alone for each area. WP Rocket’s Heartbeat control guide says its reduced mode changes a one-minute interval to one request every two minutes. In WP Rocket, we’d use reduced activity in the dashboard first. For the post editor, keep it active unless you’ve tested autosaves, post locking, and editor-based plugins. Test the change after saving, then use WP Rocket’s controls to roll it back if an admin task stops working. Set separate rules in LiteSpeed Cache LiteSpeed Cache gives you more detailed controls under LiteSpeed Cache > Toolbox > Heartbeat. You can set frontend, backend/dashboard, and editor timing separately. LiteSpeed Cache’s Heartbeat settings documentation lists defaults of 60 seconds for frontend and backend, and 15 seconds for the editor. You can set values between 15 and 120 seconds. A value of 0 disables Heartbeat in that area. Choosing to disable heartbeat in a context is more aggressive than increasing its interval. For most sites, we’d use LiteSpeed Cache to disable Heartbeat on the frontend, keep backend requests at 60 seconds, and leave the editor at 15 or 30 seconds. Simple. Safe. Much easier on server resources. Change the Interval With a Custom Snippet Custom code works when you want a lightweight fix without another optimization plugin. Add the snippet through a child theme’s functions.php file or a code snippets plugin. Use the heartbeat_settings filter The WordPress heartbeat_settings hook provides the heartbeat_settings filter for adjusting the interval without deregistering the Heartbeat script. add_filter( 'heartbeat_settings', function( $settings ) { $settings = 60; return $settings; } ); This example requests a 60-second interval. It is a sensible starting point for a low-traffic admin area. If you prefer a UI, the Heartbeat Control plugin offers a reversible alternative. Don’t use this as a blanket fix for every screen. The heartbeat_settings filter changes the interval wherever Heartbeat runs, so it isn’t context-specific unless you add conditional logic. Keep code changes easy to reverse Before adding custom code, create a fresh backup and record the original behavior. If something goes wrong, remove the snippet and clear any cache. Custom code isn’t automatically better than a plugin setting. Choose the option you can maintain confidently. If multiple people manage the site, a clearly labeled plugin setting is often less risky. Protect Autosaves, Post Locking, and Team Work The post editor is where aggressive changes hurt first. They can disrupt autosave on sites where marketing, support, and content teams work all day. Test a real editing session Open a draft in one browser. Use the post editor to make a few edits, wait for an autosave, then refresh the page. Confirm that the draft is still there. Next, open the same post in a second browser session to test post locking. WordPress should show a post locking warning. If it doesn’t, restore the editor interval or disable heartbeat before team workflows fail. Check plugins that expect live updates Page builders, learning platforms, membership tools, booking plugins, and WooCommerce extensions may use background AJAX calls for their own features. Some use Heartbeat directly, while others may depend on real-time updates. Test the tasks your business runs every week: Create and update a post or product. Test collaborative editing and post locking with two users. Let a login session sit for a while. Review plugin notices, orders, bookings, and support workflows. A setting that works on a brochure site may fail on a busy store. Test the work, not dashboard speed alone. When Hosting Needs More Than a Heartbeat Tweak Heartbeat tuning can reduce unnecessary server load. It can’t fix an overloaded shared hosting plan, inefficient plugins, slow database queries, inadequate memory, or an underpowered PHP setup with too few PHP workers. If usage stays high after you confirm and reduce Heartbeat requests, review overall site performance. Check caching, image optimization, optimization plugins, plugin cleanup, current PHP versions, and available memory. Monitor PHP workers after tuning, especially during busy periods. For site owners who want fewer technical chores, managed WordPress hosting adds monitoring, backups, security, and WordPress-focused support. That gives you a better place to troubleshoot than a generic resource warning. Growing stores and high-traffic sites may also need more isolated resources. Our guide to when to upgrade to VPS hosting can help you compare the next step without paying for more server than you need. Key Takeaways Confirm action=heartbeat before treating admin-ajax.php as the problem. Reduce the interval first, especially in the dashboard. Keep the post editor active when autosaves and collaborative editing matter. Test visitor-facing features before you disable heartbeat on the frontend. Make one change at a time, using the Heartbeat Control plugin or WP Rocket for easy rollback. Frequently Asked Questions Is it safe to disable Heartbeat on the frontend? Usually, yes, if your public-facing plugins don’t depend on it. Test contact forms, bookings, carts, membership areas, and other live features first. If you’re unsure, a longer interval is a safer first step. Will changing Heartbeat settings improve site speed for visitors? It can reduce server load from logged-in background requests. It won’t automatically make every public page faster. Page caching, hosting capacity, database performance, and plugin quality still affect visitor speed. Why is admin-ajax.php using so much CPU? Heartbeat may be part of the issue, but it isn’t the only possibility. Confirm the request action, then look for plugins or admin tools sending frequent requests. After identifying the source, a tool such as the Heartbeat Control plugin can reduce or scope Heartbeat activity. The WordPress Heartbeat API explained resource is useful when you need to separate Heartbeat activity from other AJAX traffic. Keep WordPress Responsive Without Letting Requests Run Wild The right Heartbeat configuration gives you control without taking away the admin tools that protect your work. Measure actual traffic, adjust the request interval where it makes sense, and test the editor before finishing. A stable setup also supports site performance. Lower request volume is good. Lower request volume that still preserves autosave, team editing, and admin stability under pressure is better. [...]
Read more...
WordPressWooCommerce Payment Troubleshooting When Checkout FailsA failed checkout isn’t a small glitch. It’s a customer ready to buy, then a sale that stops cold. WooCommerce payment troubleshooting works best when you follow the evidence, not guess at fixes. Start with the order record, confirm whether the gateway received the request, then test changes safely before touching your live store. Key Takeaways Check the order notes first. They often show whether WooCommerce reached the payment gateway. Use gateway logs to separate declined cards, credential errors, webhooks, timeouts, and checkout conflicts. Never retry, refund, or cancel an order until you confirm whether the gateway captured money. Test plugin and theme changes on staging whenever possible. A live checkout is not the place for experiments. Reliable hosting, backups, SSL, and responsive support make payment recovery far less stressful when something breaks. Start With the Order Record Before changing API keys or disabling plugins, open the affected order in WooCommerce > Orders. Record the order status, payment method, checkout time, and customer details. Failed orders tell you something stopped. They don’t tell you where. The order notes can show whether the payment gateway received the request. Read order notes before changing settings Order notes can show a gateway response, a failed authentication attempt, a timeout, or an error returned during checkout. WooCommerce recommends checking these notes before moving into deeper diagnostics, as outlined in its order troubleshooting documentation. Look for the exact wording and timestamp. A note saying the order moved from “pending payment” to “Failed” is useful. A note that includes a gateway error is even better. If there are no payment-related notes at all, checkout may have stopped before the gateway communicated with WooCommerce. That points you toward a checkout, plugin, theme, caching, or server issue. Confirm the time and payment method Match the order timestamp with what the customer reports. Did the checkout page spin for a long time? Did they see a card decline? Did they refresh and try again? Write down the gateway used, then check whether the same gateway is failing across multiple orders. One failed card is usually an isolated event. A cluster of failures within minutes is a store problem until proven otherwise. Match the gateway record to the WooCommerce order. Record the exact transaction ID and whether the payment used authorize and capture. A failed order isn’t proof that no money moved. Confirm the gateway’s transaction record before telling a customer their payment did not go through. Use WooCommerce Payment Troubleshooting Logs Logs provide the technical trail when failed orders have incomplete details. They show what happened behind the scenes. Go to WooCommerce > Status > Logs, choose the relevant gateway log from the dropdown, then select the date matching the failed checkout. Some older gateway documentation may call this area System Status, but the current WooCommerce path is Status > Logs. Compare the beginning and end of each attempt A useful log trail has a clear sequence: WooCommerce starts a payment request, the payment gateway responds, and the order moves to its expected state. When the first step appears but the response does not, you may be looking at a communication timeout. When the gateway returns an error, copy its code and full message before making changes. Those details matter when you contact gateway or hosting support. Pay attention to the clock. A payment error at 2:14 PM and a server error at 2:14 PM belong in the same investigation. Turn on logging only when needed Many payment extensions include a debug logging setting under WooCommerce > Settings > Payments. Turn it on while you reproduce the issue, then turn it off after collecting what you need. Logs can contain customer data, request details, API keys, card data, tokens, and complete request payloads. Store relevant entries securely, and share only the necessary redacted excerpt with support. If your dashboard is slow, requests are timing out, or fatal errors appear during busy sales periods, check whether your PHP version meets the current WooCommerce, WordPress, and gateway requirements. Then review web hosting versus VPS hosting before adding more checkout plugins. More traffic and extensions can expose resource limits that basic hosting handled poorly. Match the Symptom to the Right Fix The quickest path forward is to identify the symptom first. Common failed orders involve declines, pending payments, missing options, or stuck processing. Record the current order status before making changes. When a credit card is declined A “credit card declined” message often comes from the card issuer or a rule inside the payment gateway. Don’t assume your store caused it. Check the order notes and gateway dashboard for the response. If the same customer keeps seeing declines, ask them to confirm their card details or try another payment method. If many customers see declines, inspect your credentials, live mode settings, fraud prevention rules, and recent plugin updates. Gateway fraud-prevention rules can reject otherwise valid payments. Avoid manually changing the order to paid. Don’t refund or ask the customer to retry until you confirm whether money moved. When payment stays pending or times out A pending payment can mean the customer left checkout. It can also mean WooCommerce did not receive the gateway’s final update. First, check the gateway dashboard for a matching charge or payment intent. Confirm the order status after comparing it with that record. If Stripe shows the payment succeeded but WooCommerce still shows pending, investigate webhook delivery. If no gateway record exists, focus on the checkout request, logs, and server response. A pending payment with no matching transaction needs investigation before any retry. Timeouts deserve extra care. Customers often refresh a slow page, which can create a second order or a second payment attempt. When the payment gateway disappears A missing payment option is usually a configuration or eligibility problem. Confirm the gateway is enabled, its credentials are saved, and its currency settings and country rules match the store setup. Then test the shopper-facing checkout page while logged out in a private browser window. Cached sessions, custom checkout fields, and block-based checkout templates can change what shoppers see. If the gateway appears for one currency but not another, check both the gateway’s supported currencies and any multi-currency plugin rules. Don’t treat a multi-currency checkout as a standard single-currency test. When an order is processing or on hold Don’t change an order status because it looks stuck. Open the gateway dashboard first and confirm its authorization, capture, or transaction ID. If the gateway succeeded but webhooks failed to update WooCommerce, investigate the webhook before changing anything. Your fulfillment process matters here. Check whether staff already shipped goods, reduced inventory through stock management, or contacted the customer. Then use the order notes and gateway record to decide whether the order needs manual review, a stock management check, or customer follow-up. Confirm the order status before taking action, and don’t mark it paid without verified payment. Failed orders may need review even when fulfillment activity already occurred. Verify Gateway Settings and Webhooks Payment gateway configuration involves more than a credentials screen that looks correct. Check each setting line by line, including test mode, old webhooks, and copied credentials. Recheck Stripe mode, keys, and events Stripe test keys work only in test mode. Live keys work only in live mode. A mismatch can stop checkout fast. In the Stripe extension settings, verify the mode and matching API keys. Never paste keys into public tickets, screenshots, or shared logs. Turn on error logging for a controlled test, then review the result in both WooCommerce and the provider. The official Stripe extension documentation also covers log review, webhook checks, and payment event troubleshooting. For webhooks, confirm Stripe can reach your store’s endpoint and send a test event. WooCommerce documents payment_intent.succeeded, payment_intent.payment_failed, charge.succeeded, and charge.failed as relevant events for investigation. Refresh PayPal Payments communication PayPal Payments needs a working connection back to WooCommerce after a transaction. If payments complete in PayPal but orders don’t update correctly, review the extension’s webhook status. WooCommerce’s PayPal Payments documentation includes a Resubscribe option in the Webhook Status area. Use it only after checking the existing connection and saving your current settings. Confirm Authorize.net credentials Authorize.net setup depends on the correct API Login ID, API Transaction Key, and API Key. One old character pasted into the wrong field can block every payment attempt. Check that your account mode matches the credentials in WooCommerce. If webhook delivery appears to be the problem, WooCommerce’s Authorize.net guidance includes a webhook reset option. Save screenshots and logs before resetting anything, so you can confirm what changed. Test Plugin and Theme Conflicts Safely A payment gateway can be healthy while another extension breaks checkout around it. That’s why testing for plugin conflicts requires patience. Use a staging site for controlled tests Clone the store to a staging site, use test mode, and reproduce the exact checkout flow. Then disable one nonessential extension at a time, testing after each change. Start with cart tools, currency converters, coupon extensions, caching plugins, security rules, checkout field editors, analytics scripts, and stock management integrations. These extensions can affect checkout requests. Managed WordPress hosting gives store owners a safer place to test updates with staging, backups, monitoring, and support close by. That means less guesswork when revenue is on the line. Check the theme and checkout setup Temporarily switch to a default WordPress theme on staging. If payments start working, you’ve isolated theme conflicts or custom checkout code that needs attention. Also compare the checkout type. A custom template, a page builder layout, or a block-based checkout may behave differently than the classic checkout page. Test the same gateway with a simple, supported setup before blaming the payment provider. Prevent Duplicate Orders and Repeat Failures Duplicate orders and failed orders often follow uncertainty. A shopper sees a spinner, refreshes the page, clicks pay again, or returns to checkout while the first request is still processing. Check payment records before refunds Compare every WooCommerce order with the gateway’s transaction history, matching each order to its transaction ID. Before issuing a refund, confirm whether each payment was authorized or completed through the authorize and capture process. If two orders exist but only one payment completed, check whether the duplicate changed inventory in stock management. Stock changes don’t prove payment completion. Review the order status before canceling, refunding, or fulfilling the order. Cancel the unpaid duplicate after confirming the details. If two payments completed, investigate both transaction records before issuing a refund. Also confirm stock management records before fulfilling or canceling either order. Don’t delete the orders. Keep the order notes, timestamps, and logs for your records. Build a recovery plan before trouble hits Keep WordPress, WooCommerce, themes, and gateways updated on a schedule. Test major updates on staging. Verify that an SSL certificate is active, valid, and covering the checkout domain. Confirm that backups are recent enough to restore with confidence. Our WooCommerce hosting launch checklist covers the practical basics: SSL, backups, security checks, updates, and a restore plan. When a checkout problem turns into a wider site issue, those basics save hours. FAQ How can a failed transaction be confirmed? Check the WooCommerce order notes, gateway logs, and the gateway dashboard. A red Failed status alone is not proof that no payment was taken. What should happen after a customer reports a timeout? Ask for the order number and approximate checkout time. Then check for a matching gateway transaction before asking them to try again. This prevents accidental duplicate charges. Can live plugin conflicts be tested safely? You can, but we don’t recommend it during active selling hours. Use staging and gateway test mode so you can isolate the conflict without interrupting real customers or creating live charges. Keep Checkout Ready for the Next Sale Failed payments get easier to fix when you follow the trail from the checkout page to the order record, logs, and gateway records, then run a controlled test. That approach protects customers, protects revenue, and keeps a small issue from turning into a long support day. The strongest fix is often not a new plugin. It’s reliable hosting, safe backups, SSL protection, regular software updates, and clear stock management. Together, they help prevent fulfillment problems after an unclear payment result. [...]
Read more...
WordPressHow to Fix WooCommerce Product Images That Won’t DisplayA missing product image can make a good store look unfinished in seconds. If your WooCommerce product images won’t display, the problem is usually fixable without rebuilding your product pages or installing a pile of plugins. Start with the symptom, then fix the right layer. A blank gallery, blurry shop thumbnail, missing mobile image, and broken image link don’t have the same cause. Let’s get your storefront looking sharp again. Key Takeaways WooCommerce uses different image sizes for product pages, shop grids, and gallery thumbnails. Check that each product has a featured image, then confirm its gallery images are attached correctly. Change image dimensions before regenerating thumbnails, not after. Classic themes use the WooCommerce Customizer. Block themes often use the Site Editor and Product Gallery block instead. Upload square source images of at least 800 by 800 pixels for a reliable starting point. If pages remain slow after image fixes, your hosting environment may be the bottleneck. Identify Where the Image Disappears First Don’t troubleshoot blind. Open the affected product in an incognito browser window, then test it in a second browser or on another device. Compare the product page, shop page, category page, cart, and mobile view. Check whether the gallery remains visible and usable in a mobile friendly layout. If an image appears after a delay, note that separately from a missing file, wrong crop, or blank space. These symptoms point to different causes. For more detail, open your browser’s developer tools and select the Network tab. Look for image requests returning 404, 403, or mixed-content errors. Check the Console for blocked resources or JavaScript errors. Record the failing image URL before changing any settings. WooCommerce creates and uses different image versions in different places. One version can fail while the original image still looks fine elsewhere. Product pages, shop grids, and thumbnail strips WooCommerce has three main image contexts: Image typeWhere you see itDefault WooCommerce behaviorSingle product imageMain image on an individual product pageUncropped, 600 pixels wide by defaultCatalog imagesShop and category gridsCropped square image, 300 pixels wide by defaultGallery thumbnailsSmall gallery navigation imagesSquare cropped, 100 by 100 pixels by default The developer documentation identifies these registered sizes as woocommerce_single, woocommerce_thumbnail, and woocommerce_gallery_thumbnail. Shop and category grids request generated product thumbnail images instead of the original upload. Your theme can apply a different thumbnail style, including square, cropped, or uncropped displays. That difference explains why a clean source photo may still look wrong on the front end. If the main image displays but the shop grid shows blank spaces, focus on the catalog thumbnails. If the product gallery thumbnails are missing, check the product gallery and its generated files. If the original file works but generated catalog or gallery files don’t, regenerate thumbnails after confirming the source image and dimensions. Blank, blurry, cropped, or hidden? A broken image icon usually points to a missing file, a wrong image URL, mixed-content trouble after enabling SSL, or a security rule blocking image requests. A blank area with no icon often points to theme CSS, a page builder template, or a gallery setting that hides the image. A blurry image is different. WooCommerce notes that blurry product images often happen when a theme renders an image at dimensions that don’t match the uploaded file. Don’t re-upload the same small image and hope for magic. Check dimensions first. A cropped image usually points to the selected display size or thumbnail style, rather than a missing upload. A delayed image can indicate lazy loading, a slow image request, or a JavaScript conflict. A thumbnail regeneration job creates new versions of the image. It cannot add detail that was never present in a low-resolution original. Confirm the Product Image Is Assigned Correctly Before touching theme settings, inspect the product itself. This is the fastest fix, and it catches more errors than most store owners expect. Go to Products > All Products, edit the affected item, and check the product data area and right sidebar. Confirm the images, update the product, and test the storefront again before changing theme or server settings. Set the featured image and gallery Every product needs a featured image. This is usually the main single product image and the image WooCommerce uses in catalog views. In the Product image panel, add or replace the featured image. Then use the Product gallery panel for extra angles, close-ups, packaging shots, and detail images. WooCommerce’s product image and gallery instructions show the same workflow: select images from the Media Library or upload new files, then save the product. WooCommerce recommends source images of at least 800 by 800 pixels. If an image appears in the Media Library but not on the product, it may simply not be assigned to that product. Reattach it, update the product, and refresh the storefront. For variable products, check the variation images too. Confirm each relevant variation has an image assigned and that selecting a variation changes the displayed image. Check the Media Library file itself Open the image attachment in the WordPress Media Library. Test its direct URL in a new browser tab and confirm the file extension matches the uploaded image. A 404 error usually means the file is missing or its path is incorrect. A 403 error means the server is refusing access, often because of permissions or security rules. Restore a missing file from a backup or upload it again, and create a backup before restoring files or making server-level changes. Keep filenames simple, such as blue-leather-wallet.jpg. Avoid unusual symbols, long strings of copied text, and spaces when possible. If the URL and re-upload checks don’t solve a 403 error, don’t make broad permission changes yourself. Ask your host or administrator to verify that the uploads directory is readable by the web server. If you recently moved your site to HTTPS, inspect the image URL. A page loading through HTTPS should also load its images through HTTPS. Browsers may block insecure image calls or display warning behavior when a store mixes secure and insecure assets. After replacing or restoring a missing file, clear your page cache and CDN cache. Then test the page in a private browser window so an old broken URL isn’t being served. Fix WooCommerce Product Images With the Right Size Settings in the WooCommerce customizer Image settings aren’t one-size-fits-all. A clean square crop can work beautifully for a clothing catalog and look awful for a wide sofa, book cover, or landscape print. Consider your source photography and its image aspect ratio before choosing a fixed crop. The WooCommerce customizer helps match those source images to the layout customers see. Use the WooCommerce Customizer in classic themes In classic themes, open the WooCommerce customizer through Appearance > Customize > WooCommerce > Product Images. Before changing global image settings or regenerating files, create a backup or test the changes on staging. Then review these controls: Main image width Thumbnail width Thumbnail cropping, including 1:1, custom ratio, or uncropped The thumbnail width and crop settings affect generated product gallery thumbnails. These settings mainly affect catalog images, not the single product image in the same way. Don’t chase them if only the main product display is missing or incorrect. Choose 1:1 when your catalog uses consistently square product photos. Choose Custom for a fixed portrait or landscape shape, such as a custom aspect ratio. A fixed crop can distort products with a very wide or tall image aspect ratio. Select Uncropped when preserving every edge matters more than a neat, uniform grid of uncropped images. This thumbnail style should match your products and grid layout. Set the main image width and thumbnail width first, then choose the crop mode. Save those settings before starting regeneration. For sharper retina screens, WooCommerce recommends thumbnails that are roughly double the width your theme displays. If your grid layout displays images at 300 pixels, start with a 600-pixel thumbnail width. Regenerate thumbnails after changes Changing dimensions or cropping doesn’t rewrite image files that WordPress already generated. Regeneration also can’t restore detail missing from a low-resolution original. After saving the new settings, go to WooCommerce > Status > Tools. Find Regenerate shop thumbnails and select Regenerate. WooCommerce’s blurry image troubleshooting guide confirms this is the correct location for regeneration. Let the task finish before checking the shop page again. The WooCommerce customizer isn’t available in many block themes. If your catalog still looks wrong, back up the site and temporarily switch to a default WooCommerce-compatible theme. If the issue disappears, investigate your active theme’s CSS or templates instead of deleting product media. Find Missing Settings in Block Themes Can’t find Product Images in the WooCommerce customizer? You’re not stuck. Your site may use a modern block theme, where product templates live in the Site Editor instead. Block themes may not expose the same controls in the WooCommerce customizer. The controls moved, not because WooCommerce removed your gallery. Edit the Single Product template Go to Appearance > Editor, then open Templates and select the Single Product template. Look for the Product Gallery block. First, confirm the block exists and the template is saved. Check that the block is visible and has usable width and height. A collapsed container can make correctly assigned images appear missing. Review the block’s display settings before testing plugins. Check the product gallery slider, product gallery thumbnails, thumbnail style, and horizontal navigation. Then review the image zoom settings and lightbox mode. An autoplay slider can hide an image or move past it quickly, so disable autoplay while diagnosing the problem. If you use a product video gallery, temporarily remove or disable the video while testing. Extra gallery items can affect slider behavior. This block controls the gallery placement and presentation on product pages. You can adjust its layout without editing code or altering every product individually. WooCommerce’s Product Gallery block documentation covers the available gallery controls. Its documented defaults include square thumbnails at 25% of the main product image size. If the gallery block is missing, it may have been removed from a custom template. Create a backup or staging copy, add the block back, save the template, then test a product with a featured image and multiple gallery images. Watch for template and plugin conflicts A custom product page design, page builder, custom child theme, or product template plugin can replace WooCommerce’s default gallery markup. This can leave you with a blank gallery even when product images are correctly assigned. Test changes from safest to most advanced: Confirm the Product Gallery block exists, is visible, and is saved. Check the block’s dimensions, slider, thumbnail, zoom, lightbox, and autoplay settings. Clear page, browser, and CDN caches before testing again. Preview the product with a default WooCommerce theme. Disable gallery, slider, page-builder, and optimization plugins one at a time. Check custom CSS for rules such as display: none, overflow: hidden, zero width, or zero height. Check the browser console for JavaScript errors that prevent the slider from initializing. Don’t delete product images while testing. The product data is usually fine. The display layer is where the trouble lives. Keep Image Quality High Without Slowing the Store Large source files protect image quality, but oversized uploads can slow product pages. Image optimization balances sharp dimensions, suitable formats, and practical compression. You need enough pixels for clean zooming and responsive layouts. The delivered file should still be compact enough for mobile visitors. Oversized gallery assets can reduce page speed, especially on mobile, where product images often make up most of the page weight. Start with a strong source image Use at least 800 by 800 pixels for square WooCommerce product images. For products that need a larger gallery view, upload a larger original when it stays visually clean and reasonably compressed. Keep your product photography consistent. Use the same background, camera angle, and crop style across a category whenever possible. A uniform catalog looks more trustworthy and makes your store easier to scan. Avoid stretching a small source image to fit a large image area. WordPress can make images smaller. It can’t create the product detail that a tiny original doesn’t have. Compress before you upload Resize and compress product photos before adding them to WordPress. Use modern image formats when your theme and browser workflow support them. Compare the image at its rendered product-page dimensions, not only at 100% zoom on your computer. Check the compressed image file size while confirming that important product details remain clear. Lazy loading is useful for gallery items below the fold, since those images don’t need to load immediately. WordPress has used native lazy loading for images since version 5.5, as explained in the official WordPress lazy-loading update. Lazy loading can’t repair a missing file or a CSS-hidden gallery. It also shouldn’t delay the main above-the-fold image, and it won’t fix an oversized hero image. For more practical checks around caching, scripts, and slow server responses, use our guide on how to speed up WordPress. Image compression helps with file delivery, but it doesn’t resolve every server performance problem. Rule Out a Hosting Problem Only move to hosting diagnostics after confirming the product assignment, image settings, regeneration, theme and plugin tests, and cache clearing. If images still fail or load late, the problem may sit outside WooCommerce. Start with these checks: Open the failed image URL in your browser and note its HTTP status. Review your web server or hosting error logs for failed requests. Test the original media URL separately from the CDN URL. Ask your host to check PHP memory, image-processing limits, disk space, and access to the uploads directory. Intermittent failures during traffic spikes can point to resource limits rather than a product image setting. If a CDN serves a stale or blocked asset, purge only the affected cache, or ask the provider to invalidate it. Then retest in an incognito browser. Don’t edit server permissions, PHP limits, or CDN origin rules without a backup and hosting support. These changes can break uploads or other parts of your store. A solid store setup needs current PHP, HTTPS, enough WordPress memory, caching support, automatic backups, and room to grow when traffic spikes. Our WooCommerce hosting checklist breaks down what to look for before a slow store starts costing sales. ZADiC managed WordPress hosting gives small businesses a more dependable base with support, backups, security monitoring, and performance-focused tools. Your product photos should help sell. They shouldn’t become another technical fire to put out. FAQ Why do product images show on the product page but not the shop page? The product page may load the original product image, while the shop page uses generated catalog thumbnails. Gallery files can also use separate sizes and crops. Check the image dimensions first, then regenerate thumbnails after changing them or replacing the source file. Can a product have more than one image? Yes. One featured image serves as the single product image, while additional files belong in the Product gallery panel. Add photos that show the color, texture, size, and important details. Why are product images missing only on mobile? Test the page in an incognito window to rule out a browser cache issue. Then inspect the mobile layout for hidden containers or elements with zero height. Clear your page and CDN caches after changing the template. Why did product images disappear after an HTTPS migration? Open an image URL directly with HTTPS and inspect the page for mixed-content warnings. If the image returns a 403 error or permission error, contact your host and ask them to check file access and server rules. Get Product Images Back to Work Missing product photos usually trace to a clear troubleshooting order: confirm assignment, check image settings, regenerate thumbnails, then investigate display conflicts. Clear caching or CDN issues and rule out hosting problems before testing the product page, catalog grid, and mobile layout again. A clear, fast WooCommerce product image setup supports consistent product photography and reliable image delivery, both of which support store conversions. Sharp photos, reliable hosting, and a gallery that loads when it should keep your store moving in the right direction. [...]
Read more...