What a page knows about another page

A list can only use what a page or an article publishes about itself. That set is fixed, and it is short on purpose.

The fields

Inside a loop, each item — and the document you are on, as page — has these:

Field	What it is
title	The title.	both
url	Its address, starting with a slash. / for the homepage.	both
path	The same without the leading slash. "" for the homepage.	both
postId	Its own identifier.	both
date	Its publication date.	both
lastmod	When it last changed.	both
excerpt	The short summary from its settings.	both
image	Its own picture, or nothing.	both
tags	The words it is grouped by, as a list. Empty when it has none.	both
parent	The address of the page, or item, it sits inside, without slashes. "" at the top level.	both
parentId	The identifier of that parent, when you need the id rather than the address.	both
order	Where it sits among its siblings, as a number.	both
fields	Its values for its collection’s fields — p.fields.client. See Collections.	items

parent, parentId and order place a document among its siblings. A page sits in the page tree. An item sits in its own collection, in the order you dragged it into, and has a parent only when its collection is hierarchical: in a flat collection like Articles, parent is always "". An item never sits under a page. See Articles. fields is the other way round: only an item of a collection has one.

tags is the one that is a list rather than a single value, so it behaves differently from everything else in the table. .size, .first and .last work on it — as they do on site.pages and collections.articles — and nothing else does: to read the words, loop over it or use | join. See Tags.

One shape, current document or listed one

page.title and post.title inside a loop mean the same thing, because they are the same shape. A block written against one works against the other, which is what lets a card design be used by an index and by the page itself.

page means whatever is being served — a page or an article. There is also item, which is set only while an article (or any collection’s item) is being served, for the times a shared block needs to tell:

{% if item %}
  <p class="byline">Published {{ page.date | date: "%-d %B %Y" }}</p>
{% endif %}

A block that reads {{ page.parent }} on an article gets an empty value rather than an error, because an article in a flat collection has no parent. That is what lets one header work on both without being written twice.

The one place this is deliberately strict: image is the page’s own picture and never falls back to the site’s. A field that meant something different on the current page than on a listed one would break exactly that property.

A picture has its own fields

When a page has one:

{% if page.image %}
  <img src="{{ page.image.src }}" alt="{{ page.image.alt }}">
{% endif %}

src and alt are always there. width, height, avif and webp are present for an uploaded photograph and absent for an external image or a vector, so guard those the same way if you use them.

What a list cannot reach

The body of another page or article. A loop can show you a title, a summary and a picture — it cannot show a paragraph out of the middle of something.

That is a deliberate line rather than a gap. The index is built from a compact record of every page and article; reaching into bodies would mean loading the whole site to render one listing.

If you want a sentence from an article to appear on the index, put it in that article’s excerpt. That is what the field is for.

Getting a field name wrong

You cannot, quietly. A name that is not on the list above stops the site publishing, and the message names the field and lists the real ones. See When something is wrong.