Key takeaway
A submitted listing is a lead, not a finished public card. It starts a source check that tries to confirm the durable details a reader needs before driving, ordering, or saving a place for later.
The public version should be useful without pretending to know more than the sources support. Strong details move forward. Thin or conflicting details wait, get softened, or stay out of view until a better source appears.
A listing starts with a source
The first useful question is simple: what source points to this place? A restaurant site, location page, official menu, ordering link, or current public profile gives the listing something durable to stand on.
A name by itself is not enough. The source has to connect the name to a location, a pizza-relevant offering, and a way for a reader to verify the basics. If the place has multiple branches, the source also has to make the location clear.
This is why the site treats submissions as leads. A reader can help point at a restaurant, but the public card still needs its own source trail.
For the source standard behind those checks, see How Peace Love and Pizzas Checks a Listing.
Review fills in the public card
Once the basic identity is clear, the next step is matching source types to the fields they can safely support. The goal is not to make every row look full. The goal is to make each visible row honest.
Different sources enter the lifecycle at different points. Some help identify the place. Some support menu and pizza-style fields. Some help resolve conflicts. Some are only good as a lead for another check.
| Source type | What it can support | What it cannot support | What happens if it disagrees with another source |
|---|---|---|---|
| Official site | Business identity, location page, owned links, and current service language | A quality score or broad ranking | The conflict gets resolved against newer or more specific owned pages when possible |
| Official menu or order page | Pizza availability, item names, style clues, sizes, and price signals | A guarantee that every item is available every day | The card keeps the narrower menu-backed detail and avoids broader guesses |
| Official social profile | Recent closures, events, limited items, or temporary changes | A durable field by itself when the post is old or incomplete | The detail waits unless another current source supports it |
| Map or business profile | Address cross-checks, phone clues, and public location context | Dog, patio, dietary, accessibility, or price details on its own | It can flag a mismatch, but the card needs a stronger source before changing sensitive fields |
| Reader correction | A pointer to a field that may need attention | Finished public copy without source support | The correction becomes a task to check, not a public fact by itself |
Some claims wait
A useful public card can still leave fields blank. That is better than filling a field with a confident guess, a stale clue, or language copied from somewhere else.
Waiting is especially important for fields that change quickly or depend on local conditions. Hours, ordering setup, location-specific branch details, and policy details need stronger evidence than a casual mention.
The correction loop
Corrections are useful because they show where a listing may be stale, thin, or confusing. A correction does not have to solve everything. It can point to the exact field that needs another look.
The strongest corrections name the field, explain what looks wrong, and point to a source. The weakest corrections ask the card to change without showing how a reader could check the detail.
When a correction is strong, it can help update the listing. When it is partial, it can still improve the work by marking the next source check.
That same lifecycle shows up on city pages too: a local guide is most useful when each place has enough sourced detail to help a reader compare options, as explained in How a City Page Becomes Useful.
Common mistakes
Most listing problems come from moving too quickly. A lead gets treated as a finished fact, a broad brand page gets treated as a branch page, or an old public clue gets treated as current.
The safer habit is to slow the card down until each field has the right kind of support. If a detail is useful but not verified, it can wait for another pass.
FAQ
These are the questions that usually come up when a submitted place is not public yet.
Why is a submitted place not public right away?
Because the listing still needs source support for the practical fields readers rely on. A lead can be useful before it is ready to appear as a public card.
Can a card publish with some blank fields?
Yes. Optional fields can be omitted when the core identity, location, and pizza-relevant facts are strong enough. Blank is safer than a guess.
What helps a correction move faster?
Name the field, describe the issue, and point to the clearest current source. A correction with a source trail is easier to check than a general note.
Source and provenance note
This article describes an editorial workflow, not a promise that a specific submitted place will appear. Each public listing still depends on source support, duplicate checks, and a final read against the visible fields.
The public goal is simple: show useful restaurant facts that a reader can understand and recheck, and leave out the fields that are not ready yet.
Editorial note
This article explains the listing lifecycle at a general level. It is not a restaurant endorsement, ranking, or guarantee that any specific place will be added.
FAQ
Why is a submitted place not public right away?
Because a submitted place is only a lead until the practical fields have enough source support for readers.
Can a listing publish with some blank fields?
Yes. Optional fields can be omitted when the core identity, location, and pizza-relevant details are strong enough.
What makes a correction useful?
A useful correction names the field, explains what changed, and points to a current source that can be checked.