Useful by design.
Careful by default.
How Website Unpacked selects examples, supports its observations, and makes room for corrections.
How we curate examples, label technology findings, credit sources, and handle corrections.
Choose examples for
what they can teach.
Industry guides should help a reader understand real design decisions. Examples are selected for useful contrasts in content, navigation, project presentation, visual hierarchy, and the way a practice or business explains itself. A collection should not be a list of interchangeable screenshots assembled to meet a target number.
“Best” means an editorial selection of examples worth studying. It is not an exhaustive ranking or a measured claim about traffic, revenue, search position, accessibility, performance, or security. The order of examples is a reading sequence unless a different method is explicitly explained.
The directory can include planned industries, but those entries must remain clearly distinguished from completed guides. A planned label does not get a placeholder article or a link to a missing page.
Look at the website.
Then explain the decision.
- Start with a reader’s question.
Define the industry, audience, and decisions the guide is intended to help with. A small studio and a global organization do not automatically need the same navigation or content model.
- Use the official source.
Open the live website, identify the view being reviewed, and record a capture and review date. A homepage, a project index, and an individual case study should not be presented as if they were the same page.
- Write an original observation.
Name the specific pattern, describe what it makes clearer, and explain what someone else can learn from it. Avoid unsupported claims that a visual choice caused more leads or sales.
- Include the tradeoff.
Pros and cons are design judgments, not findings from an audit we did not perform. Make conditional concerns explicit: a motion-led opening needs a useful fallback; a large taxonomy may be unnecessary for a small portfolio.
- Check the supporting details.
Verify names, URLs, project references, capture labels, and technology signals. If a fact cannot be supported, qualify it, leave it out, or identify it as unknown.
- Review before publication.
Check that the words, images, sources, links, and tool behavior agree. A draft remains a draft until it is ready for an actual reader.
A clue is not
the whole stack.
Technology notes should identify the public signal behind a label: a generator tag, a distinctive framework bundle, a core or theme asset path, a response header, or an explicitly published development credit. Keep supporting evidence in the source notes. Reader-facing technology lists should distinguish an asset service from a full CMS and omit unconfirmed components. A documented platform attribution, such as an official Showcase listing, must be identified as such rather than presented as a fresh infrastructure audit.
A Next.js bundle identifies frontend tooling, not the CMS or the author. A Sanity image URL identifies asset delivery, not the complete publishing setup. A WordPress-style path can be a legacy asset rather than proof of the current architecture. Missing metadata does not establish that a site uses a custom CMS.
The AI website checker reports supported public builder attributions and platform clues. It does not certify authorship, assign an invented AI percentage, or declare a site human-made because it found no marker. Badges and metadata can be copied, removed, or retained after substantial changes.
The accessibility checker uses a bounded, non-executing HTML parser to look for common source-level issues on one public page. It does not render the target page or test keyboard access, screen-reader behavior, computed contrast, or dynamic states. Its separate contrast panel evaluates two opaque colors against specified text-contrast thresholds. Neither check establishes ADA or WCAG conformance. Each tool should state what it checks, what it does not check, and when the evidence is insufficient.
Assistance does not
replace responsibility.
Website Unpacked was developed with AI assistance. AI tools can help organize research, draft copy, inspect public code signals, and build interfaces. Their output is not an independent source, an eyewitness account, or evidence that a claim is correct.
The publishing standard is to verify factual claims against appropriate sources, review the actual website, and check the finished content and tool behavior. Do not invent client experience, quotations, testimonials, headshots, measured results, a technology stack, or a review that did not happen.
Personal background should come from Kegan’s own information and published work. First-person statements must not imply that he personally conducted a test or experienced an event solely because an AI system generated the sentence. Material uncertainty should be visible to the reader.
Credit the source.
Keep ownership clear.
Reviewed websites, photographs, logos, and designs belong to their respective owners. A screenshot is an editorial reference, not a portfolio claim, a reusable asset pack, or permission to reproduce someone else’s work.
Captures should be dated and linked to the source. A project-index capture should be labeled as a project-index view. An agency or developer credit should only be included when it can be verified, and should not be inferred from the visual style.
Screenshots appear alongside original commentary and links to their sources. Rights holders can raise an attribution or image-use concern with the relevant page, image, and details. Do not substitute generated imagery for a real website capture without an unmistakable label.
Real dates.
Meaningful corrections.
A review date should describe when the website or evidence was actually checked. A small spelling correction is not a reason to make an old review look newly researched. Substantive changes—new examples, refreshed captures, a changed platform, or a corrected conclusion—should be reflected in the update record.
When a correction is supported, fix the affected claim and any connected captions, technology notes, links, or tool explanations. If a change materially alters the meaning, add a short note explaining what changed. Do not silently turn an unsupported claim into a new one.
To report an issue, include the Website Unpacked page URL, the specific statement or image, the proposed correction, and a source we can inspect. The corrections contact is available without a website submission fee. No response-time guarantee is implied.
Make relationships
easy to see.
Kegan also operates a freelance web design and development business at keganquimby.com. Links to his work or services should identify that relationship. A project from his own portfolio should not be presented as an unrelated third-party endorsement.
If affiliate links, advertising, or sponsored features are introduced, label them clearly where the reader encounters them. A commercial relationship is not evidence that a website is better designed or that a tool is the right choice. Paid material should remain distinct from editorial evaluation.
No listed practice paid for inclusion in the website inspiration collections. Submitting a website for consideration should not be described as buying an editorial recommendation or a guaranteed position.
A named curator.
An open route back.
Kegan Quimby is the creator and curator of Website Unpacked. His perspective comes from 15+ years of freelance web design and development work with 250+ clients. Read more about his background.
These standards should be reviewed as the publication grows. If the product introduces contributors, sponsorship, saved tool results, or other new behavior, the published explanation should change with it rather than leaving readers to infer how the site works.