Yearbook.domains · The naming & continuity layer · A planned service
A school’s yearbook lives at a URL — and that URL is usually owned by whoever set it up that year: a vendor, an IT staffer, a platform login. When the vendor contract ends, the webmaster leaves, or the district migrates platforms, the address dies, and every link alumni bookmarked, shared at reunions, and cited in scrapbooks returns a 404.
Yearbook.domains is the layer that fixes exactly that: a permanent, portable address for the digital yearbook archive, held for the school rather than by one account, with a naming scheme for every graduating class and a redirect-not-delete custody plan. It is the address and the custody of it — not the tool that makes the book (that is yearbook.software) and not the photo curation (that is yearbook.photos).
Planned service This page reserves interest and starts a conversation. It does not register a domain or take a payment.
Record of a durable address
Illustrative · the planned modelThe failure this fixes
None of them is exotic. Each one happens on a normal school calendar, and each one breaks the address for a different mechanical reason.
The link-rot problem
A pain-point card names a feeling. Each of these names a mechanism — the specific thing that stops the link from resolving — because that is what determines whether a fix is real.
A yearbook published as a page on a vendor’s hosting is only reachable while that vendor keeps serving it. The address is the vendor’s; the school is a tenant. The month the renewal is not paid — or the year the district picks a different vendor — the page returns a 404 or a parked-domain placeholder, and there is nothing the school can do from its side because it never held the address.
When a domain is registered to one employee’s personal registrar login, the district is not the registrant of record — that account is. Recovering it after the person leaves means proving control of an email address and a payment method the district never had. In the meantime the renewal notice goes to a mailbox no one reads, and the name lapses into the open-to-register pool where anyone can take it.
Reunion invitations, alumni newsletters, class Facebook groups, and printed scrapbook captions all cite a specific URL. A migration that changes the path structure — even on the same domain — turns every one of those citations into a dead link at once. The content was carried over; the addresses were not, and no one can retroactively edit a link printed in a 2011 program.
Schools are increasingly expected to keep a durable public record of published work, and a yearbook is part of that record. But “keep it reachable for the long term” has no owner: it is not the outgoing vendor’s job, not the departed staffer’s, and not written into anyone’s role. An address with no named custodian is an address that expires by default.
How custody works
This is the actual mechanism, described as the plan — not a live legal claim. The point of the whole product is that the address stops depending on any one login, so here is exactly who holds it and what happens at each fork.
The plan is that the durable name is held for the school, not by an individual. The registrant of record is the institution — the district, or the booster club or alumni association that funds it — with Yearbook.domains named as the technical contact that keeps the renewal and the DNS from ever depending on one person’s inbox. This is the planned model, not a live legal arrangement: nothing on this page assigns a registrant or transfers a name today.
The planned policy is redirect-not-delete. A name in the program does not drop the moment a renewal date passes: it enters a grace window during which the archive stays reachable and the school is contacted through more than one channel. If the name is ever retired, the plan is to redirect its links to a standing notice with the school’s current address — not to let the name fall into the open pool where it can be re-registered by a stranger.
The plan supports both postures. A district that runs its own DNS can take delegation and point the name wherever it wants, with Yearbook.domains holding only the registration so it cannot be lost. A school that does not want to manage records can leave the pointing to us and simply say where the archive lives. Either way the SCHOOL decides the destination; custody of the name is the part that is kept from depending on one login.
Continuity is worthless if it becomes its own kind of lock-in. The plan is that the name is transferable out on request to any registrar the institution names, with the authorization code released to the institution — the same portability whose absence strands a domain in a personal account today. A permanence promise you cannot walk away from is not permanence; it is a different vendor to be trapped by.
The naming scheme
A yearbook is not one page — it is a new edition every year, for decades. The naming scheme carries all of them under one durable domain, so last year’s address still resolves and a link printed in an old program can be made to resolve again.
| Address | What it holds |
|---|---|
| centralhigh.yearbook.domains | The school’s permanent front door — always the current archive index |
| 2027.centralhigh.yearbook.domains | The class of 2027 edition, at an address that never moves |
| 2026.centralhigh.yearbook.domains | The class of 2026 edition — last year’s address still resolves |
| 2011.centralhigh.yearbook.domains | A back-catalog year, reachable from a link printed in the 2011 program |
| district.yearbook.domains | The district registry — one convention across every building |
For a district, the same convention runs across every building and is held centrally — so a family that moves across town finds the same address shape, and no single school’s one-off choices strand the others. The addresses above are illustrative; the real convention is set with the district.
The permanence model
Continuity costs a small amount every year forever, so the real question is who remembers to pay it. Each model below answers that a different way. Every figure is the planned launch model — there is no checkout on this page and no money moves through it.
The ordinary model: the name is renewed each year, funded from the yearbook budget the way any recurring line is. The difference from doing it yourself is that the renewal and the DNS do not depend on one person still working here. Figures are the planned launch model; this is not a live checkout.
A one-time contribution sized to fund renewal in perpetuity, so no future budget cycle has to remember the name. This is the model a reunion committee or booster treasurer asks for when the goal is “this link should still work at our 50th.” It is described here as a planned funding structure — no money moves through this page, and no endowment is collected today.
One convention, one custodian, every building — so a family that moves across town finds the same address shape, and the district holds the names centrally instead of discovering that each school did it differently. Planned model; pricing is the blueprint, not a live agreement.
Doing it yourself vs. a held address
Nothing here is magic that a careful IT department could not do. The difference is that the careful IT department is one resignation away from all of it, and this layer is built so it is not. Verdicts marked “planned” are the planned model, not a live capability.
| Continuity property | Domain set up in-house | Yearbook.domains (planned) |
|---|---|---|
| Address survives a vendor contract ending | No - the vendor holds it | Yes - held for the school |
| Survives the webmaster or IT staffer leaving | No - stranded in a personal account | Yes - not tied to one login |
| Old shared links keep resolving after a platform migration | No - the path structure changes | Planned - the name outlives the platform |
| A missed renewal drops the name into the open pool | Yes - expires by default | No - grace window, redirect not delete |
| You can walk away and take the name with you | Depends who holds the account | Planned - transferable out on request |
Where this sits
The yearbook product is several layers. This is the naming and identity one. Keeping the layers separate is the point: the address should outlive whichever tool made this year’s book, which is only possible if the address is not part of that tool.
What this page does not do
A continuity promise is only worth anything if it is precise about its own limits. Here is what this page is not, so nothing on it can be read as a capability it does not have.
No. Nothing on this page purchases, transfers, or provisions a domain. This surface reserves interest and starts a conversation; the registration itself is handled off this page, as a service, once there is an agreement.
No. There is no checkout and no card capture on this page. Every figure is the planned model, and every button opens an email or an early-access reservation — not a payment.
Not by magic. Preserving old links is a redirect plan we set up as part of onboarding a name; it is real work done with the school, not a switch this page flips. Where an old address is not under our control we say so plainly rather than imply we can revive it.
No — that is a different product. Yearbook.domains is the address and the custody of it. The book is produced and edited in yearbook.software and its photos are curated in yearbook.photos; this layer only makes sure the finished archive keeps a name that resolves.
Questions
No. yearbook.software is where the book is produced and edited. Yearbook.domains is the naming and continuity layer — the permanent, portable address the finished archive lives at, and the custody arrangement that keeps that address from dying when a vendor, a staffer, or a platform changes. You can hold the address here whether or not the book was made in our tool.
No. The address can point at wherever the archive already lives. The whole idea is that the name is independent of the platform: if you migrate later, you update where the name points and every shared link keeps working, because the links were to the name, not to the old platform.
The plan is that the institution is the registrant of record, with us as the technical contact so the renewal and DNS never depend on one person’s inbox. This is the planned model, not a live legal arrangement — nothing on this page assigns a registrant today. And it is portable: the plan is that you can transfer the name out to any registrar you name, with the authorization code released to you.
The planned policy is redirect-not-delete: a name enters a grace window rather than dropping the day a date passes, the school is contacted on more than one channel, and if a name is ever retired its links are redirected to a standing notice with the current address rather than released into the open-to-register pool.
Through class-year subdomains under one durable domain: a permanent front door for the current archive, plus a stable per-year address (for example a 2027 subdomain) that never moves once it is set. Back-catalog years get the same treatment, so a link printed in an old program can be made to resolve again.
Yes, that is the district registry model: one naming convention across every building, held centrally, so the addresses are consistent and no single school’s choices strand the others. It is described here as the planned model; the specifics are set with the district, not on this page.
No. The one-time endowment is a planned funding STRUCTURE — a way for a booster club or alumni association to fund renewal in perpetuity — described so you can evaluate it. No money moves through this page and no endowment is collected here; the button opens a conversation.
The address itself is just a name that resolves to wherever the archive is served. It carries no roster and no personal data. The consent posture of the archive’s CONTENTS is owned by the products that produce it (yearbook.software, yearbook.photos); this layer does not change or re-claim it.
Reserve early access
Tell us the school or district and where the archive lives today, and we will map the durable name and the class-year scheme with you. This reserves your interest and starts a conversation — it does not register a domain and it takes no payment.