When something is wrong

Publishing checks every template before anything goes live. If it refuses, the message names the page, the expression and the fix — they are written to be read rather than logged.

Nothing broken reaches the live site

The check runs against your drafts, and a failure leaves the live site exactly as it was. You have not half-published anything.

The ones you are most likely to see

Filters in a {% for %} are ignored

filters in a {% for %} are IGNORED — the loop runs over everything. Assign the list first

The one real trap in the language, and the reason it blocks rather than warns: the page renders fine and lists the wrong things. Move the filters to an assign — see Sorting and filtering.

A field that does not exist

a page has no “summary” — it has postId, title, url, path, date, lastmod, excerpt, tags, image, parent, parentId, order

Usually a near-miss: summary for excerpt, slug for path, name for title. The message lists the real fields, so the fix is in the error.

This is also what you get when a field is renamed underneath you — which is why the check exists rather than trusting that a template that worked still does.

A where with nothing to match

“where” needs a value to match — where: “tags”, “recipes”

where takes a field and the value that field has to have. One argument alone reads as “keep the items that have this”, and it does not do that — so it is refused rather than left to return nothing quietly. Test the field inside the loop instead. See Sorting and filtering.

A Liquid tag that is not in the vocabulary

its markup does not parse: tag “include” not found

Liquid exists in several products with different tag sets. Things like include, section and paginate belong to other ones. The tags here are the ordinary Liquid ones plus render, the guard every form carries, and item_body, which only a collection’s layout uses.

Nothing after a parse error renders, which is why this one stops the check rather than adding to a list.

Warnings are not refusals

Some things are reported without blocking — they might be exactly what you meant. A publish with warnings goes out, and the warnings are there to be read afterwards.

The one worth reading every time:

no page or article has the tag “recipies”, so this list is empty. This site uses “bread”, “news”, “recipes”

A tag you have not used yet is a perfectly good empty list, which is why this does not refuse. But it is also what a retag leaves behind: change the last sourdough article to bread and the sourdough page still renders, still looks right, and lists nothing. See Tags.

The line is: structurally broken blocks, anything that might be deliberate warns. A check that blocked on taste would become a thing people learn to fight.

If the message does not help

Say what you were trying to do in the AI panel and paste the message. It reads the same error, and it wrote the markup in the first place.