Replacing a bad menu photo on DoorDash, Uber Eats, Deliveroo or Glovo is not the risky part. Editing the item around it is. A photo swap that touches only the image keeps the item live, keeps its order history and keeps whatever position it has earned. A photo swap that also edits the name, description, price or category can send the item back through review and take it offline while a moderator looks at it.
Change the photo, leave the item alone. That single rule prevents almost every self-inflicted outage in a menu photo refresh.
Quick answer
Refresh delivery-app photos one item at a time, in the item editor, with the photo as the only change. Do not edit the description in the same save, do not touch the price, and do not upload a whole menu export mid-service. Shoot and prepare the replacement images first, then publish them in small batches during quiet hours, and check each item on a phone after it saves.
What actually happens when you change a photo
Every platform handles an image change slightly differently, but the pattern is consistent: the image is validated, sometimes moderated, and the item is re-indexed. The part operators feel is the validation window, not the ranking maths.
| Change you make | Typical effect | Risk level |
|---|---|---|
| Photo only, same item, same fields | Image updates after processing; item usually stays live | Low |
| Photo plus a small description tweak | Content re-review on some platforms; item may pause | Medium |
| Photo plus price change | Price change is the sensitive one; expect a review path | High |
| Bulk menu file replacing many items | Whole-menu re-processing; errors can hide in the file | High |
Two practical consequences follow. First, the safest unit of change is one item and one image. Second, a photo refresh is an operations project, not a marketing stunt, so it belongs in a quiet window rather than at 19:30 on a Friday.
The three ways operators lose momentum during a photo swap
- The accidental edit. The item editor saves everything on the page, so a stray keystroke in the description or a re-selected modifier group travels with the new photo. Read the whole form before saving, not just the image field.
- The bulk upload that half-applies. Menu export files are unforgiving about column order, headers and character encoding. If one row fails validation, platforms differ on whether they reject the file or import the good rows and silently drop the rest.
- The stale cache. After a successful save, the old image can still appear on the customer app for a while. Operators re-upload, then end up with duplicates or a second review. Wait for the processing window before concluding the upload failed.
A one-at-a-time rollout that protects what you have earned
- Prepare every image before you touch the platform. Export the final crops, check them at thumbnail size, and name files so the dish and the crop are obvious. A naming convention saves you from uploading the wrong file to the wrong item. Our file naming convention for menu photos covers this.
- Prioritise by revenue, not by how bad the photo looks. Your top ten sellers by order count should be refreshed first; a poor photo on a high-volume item costs more than a poor photo on a slow item.
- Work in batches of five to ten items. Large enough to make progress, small enough to check by hand.
- Publish during a quiet window. Mid-afternoon on a weekday is usually safer than a service peak.
- Verify on the customer app, on a phone. The merchant dashboard preview is not the customer view. Check the item in the app, at thumbnail size, with the overlay text the platform draws on top.
- Record what changed. A simple sheet with item, old file, new file, date and reviewer turns a risky manual process into a repeatable one.
Worked example (illustrative)
A 40-item menu needs 12 photos replaced. The operator does not export a new menu file. Instead:
| Week | Work | Check |
|---|---|---|
| 1 | Shoot and prepare all 12 images; approve them against the real dishes | Each image reads at thumbnail size; portions match what the kitchen serves |
| 2 | Publish the 6 highest-volume items, 2 per quiet window | Item still live; new photo visible in the customer app |
| 3 | Publish the remaining 6 items | Same check; no duplicate images left in the library |
| 4 | Compare order mix and refunds for the touched items | No not-as-pictured complaints tied to the new images |
The example is illustrative, not a customer result. The point is the shape: prepare everything, publish in small batches, verify from the customer side.
What you can safely change in the same edit
If a photo is wrong because the dish changed, the description probably needs to change too. That is a content update, not a photo refresh, and it deserves its own scheduled window with its own verification. Keep the two jobs separate:
- Photo refresh: image only, batch of five to ten, verify on the customer app.
- Item content update: name, description, price or modifiers, planned deliberately, with the printed menu and the POS checked afterwards.
Mixing them is how a photo improvement turns into a price discrepancy between the app and the till. For the seasonal version of this discipline, see the menu photo refresh calendar.
Limitations
- Every platform validates and moderates images differently, and the rules change without notice. Nothing here overrides the current merchant help pages for your market.
- You cannot guarantee that a new photo improves ranking, conversion or order volume. You can only remove a clear weakness and make the item easier to judge.
- Some platforms place a review hold on any change, including photos. Plan for the item being unavailable briefly and choose the window accordingly.
- Processing and cache delays are outside your control. A photo that looks stale for an hour is not necessarily an upload failure.
- Never publish an edited image that changes ingredients, portion or container. The quality signals that matter to delivery platforms start with the photo matching the food.
Frequently asked questions
Does changing a delivery-app menu photo take the item offline?
Usually not when the photo is the only change. The item is more likely to pause when the same save also edits the description, price, category or modifiers, because those fields carry more commercial weight and may trigger a review.
Can I upload all my new menu photos at once?
You can, but a bulk menu file is the highest-risk path: one bad row can reject the file or import partially. Small batches in the item editor are slower but far easier to verify and recover from.
How long before the new photo shows in the customer app?
Expect a processing window rather than an instant swap, and expect the old image to persist in some views longer than others. Check again after the processing window before re-uploading, which is how duplicates are born.
Should I change the description while I am in the item editor?
Only if the dish itself changed. Keep a photo refresh photo-only. Content edits belong in a planned update where the POS, the printed menu and the app are checked together.
What should I check after a photo goes live?
Three things: the item is still available to order, the new image is the one customers see, and the dish still matches the description and the portion the kitchen sends. Repeat that check on a phone, not on a desktop dashboard.
Next step
Pick your five highest-volume items, prepare clean replacement images, and publish them photo-only in the next quiet window. If you need consistent, menu-ready images from your own dish photos, start with one real dish in the FoodPhoto studio and check the current allowances on the plans page.
