Collections (Services, Areas, Reviews & More)

Collections

Skill level: Beginner · Files: src/content/<collection>/<language>/, defined in src/content.config.ts

A collection is a folder of similar entries: services, service areas, reviews, job openings, blog posts. Most entries are one file and one page. The list page of the collection (for example /areas/) takes its title and section blocks from the -index.md file in the same folder. Files whose name starts with _ are ignored.

Add An Entry

1. Copy an existing entry in the folder, for example src/content/areas/english/elm-park.md.
2. Rename the copy. The file name is the entry’s id and its URL (/areas/lake-view/) unless you set customSlug. Other files refer to entries by this id, for example area: "elm-park" in a review.
3. Change the frontmatter values and the Markdown body. Keep the keys.
4. Add the same file in french/ with the translated text and the same file name.

To hide an entry, set draft: true. It still shows in npm run dev, but it is left out of the built site, the lists, and the sitemap. npm run astro-check reports a missing required field or a value of the wrong type in every collection that has a schema.

Every Collection

yes (page) means the collection uses the shared page schema: the fields every page accepts plus every named block. astro-check checks those blocks too.

The fields every page accepts (title, description, image, draft, customSlug, SEO fields) work on the entries of every collection except reviews and author, which have their own short schemas. They are listed in Pages. The tables below list what each collection adds. Required fields must be present; all others are optional.

Services

One file per service in src/content/services/english/, plus -index.md for /services/ and the shared settings. Full guide: Services & What’s Included.

Only in -index.md: trades (id, label, icon, order, description, image), rooms (the task dictionary every included table reads), detail (blocks shared by every service page), and templates (blocks per template). The price of each service comes from the rate card with the same id in the pricing file.

Pricing

One file, src/content/pricing/english/-index.md: the pricing page and the price data the whole site uses. Fields: rounding, frequencies (id, label, discount 0 to 100, default), rateCards, addOns (id, label, price, services, task, description), jumpNav, ratesSection, and the page blocks. Keep every number identical in the English and French files: npm run build prints a [pricing] warning listing the keys that differ. Full guide: Pricing & Estimator.

Areas

One file per service area. Full guide: Service Areas.

Reviews

One file per review, with its own schema (not the page schema). Full guide: Reviews & Projects.

Homio never adds review stars to structured data: reviews hosted on your own site count as self-serving for Google. The sample reviews are invented: replace them with real ones, with the customer’s consent.

Projects

One file per finished job. Fields: ticket (job number), trade, service, area, industry (ids), featured, before, after, beforeAlt, afterAlt, caption, duration (text), crewSize (whole number), scope (check rows), price (amount, note), quote (text, name, detail), and gallery (more before/after pairs). Only in -index.md: relatedProjects. Several sample “before” photos are dulled copies of the “after” photo: replace them with real matched pairs.

Industries

One page per kind of site (offices, clinics, rentals…). Fields: eyebrow (short name), code, weight (order), action (walkthrough or book, default walkthrough), bookService, schedules, services (service ids), serviceNotes, price (service, label, unit), ticket, needsTitle, needs, scopeTitle, notCovered, faq. Only in -index.md: industryField (the form field that lists industries) and detail (blocks shared by every industry page).

Careers

One file per open role:

Dates, pay, and type feed the JobPosting data search engines read. Keep only real, open roles: replace or delete the samples before launch.

Team

One file per member, plus -index.md for /team/. Fields: title (the name, first name and last initial), profession (role), trade, area, since (year), languages, knownFor (up to 90 characters), image (optional 4:5 portrait), weight. Members have no page of their own, and no personal email, phone, or social links. The schema is strict: a misspelled field fails astro-check.

Blog And Authors

• Posts are .mdx files in src/content/blog/english/: title, description, image, imageAlt, date, updated, author, categories, tags, featured (the lead post on /blog/), service (a rate-card id: the price band at the end of the post), and draft.
• Authors live in src/content/author/english/, one file per author: title (required, the name), role, image, description, links. A post’s author: "Tom B." matches tom-b.md.
• Posts per page: blogPagination in [settings] of config.toml.

See Writing Content for the shortcodes you can use in posts.

Do It With AI

Add a [service | service area | review | project | job opening | team member | blog post] to
src/content/[folder]/english/ for: [DETAILS]. Copy the frontmatter keys of an existing entry in
that folder, keep its comments, and fill in my values only. Check the field types in
src/content.config.ts, and use ids that already exist for trade, service, and area. Then create the
French version in src/content/[folder]/french/ with the same file name, and run npm run astro-check.