Project proof
Make the relationship between repo, live site, and author clear
A project note is easier to trust when the source archive, project page, main website case study, and author profile all point to each other naturally. The goal is not to turn a project into marketing noise; it is to make the evidence easy to understand without exposing private files, stale builds, or unsupported claims.
Archive setup
Start with the source archive surface people already see
Many people first encounter a project through a profile link, a source archive page, or a case-study card. The archive should quickly explain what the project does, whether the snapshot is current, what files are safe to download, and which canonical page gives the human-friendly context.
Archive description
Use a specific one-sentence description. Include the project type, purpose, and status without broad keyword lists or unsupported audience claims.
Canonical project URL
Point each source page to the strongest project note or case study. That keeps the archive useful without making raw downloads carry the whole explanation.
Safe archive files
Keep ZIP and bundle downloads separate from indexable HTML pages, and keep raw archives out of search snippets where `noindex`/`noarchive` is appropriate.
Snapshot notes
Record the date, source branch or bundle, and any limitations so future profile copy does not imply a project is newer or more complete than it is.
README structure
Write the README like a compact project brief
A useful README is both a developer entry point and a public evidence page. It should help a future collaborator, recruiter, client, or search engine understand what is real without needing private context.
What it does
Open with the problem, intended audience, and current status. If the project is experimental, say so plainly.
Owned links
Link to the project page, main-site case study, profile hub, and any relevant documentation. Avoid dumping every profile link into every archive note.
Setup and stack
Include installation steps, environment notes, major dependencies, data sources, and deployment notes where they are relevant and safe to publish.
Limitations
Known limits, data caveats, and maintenance notes build more trust than pretending a side project is a finished enterprise product.
Live page SEO
Give the public source archive page its own search signals
A public source archive page can be lightweight and still be understandable. Each project-note page should tell search engines and readers the title, description, canonical URL, preview image, author relationship, and where to find the source.
Title and description
Write a page title that names the project and a meta description that explains the practical value. Avoid generic titles like "Home" or "React App".
Canonical and sharing tags
Use a self-canonical URL for the project page and Open Graph/Twitter tags so profile posts and project links preview cleanly.
Structured data
Use WebSite, SoftwareApplication, CreativeWork, or WebApplication schema only where it genuinely fits. Link the author entity consistently.
Project links
Include visible links to the source archive, detailed case study, and author profile. The loop should be clear without overwhelming the page.
Evidence loop
Preserve proof for profiles, CVs, and future updates
Project pages become more useful when the evidence is durable. Screenshots, validation results, commit hashes, and short case-study notes make it easier to reuse the project accurately on LinkedIn, CVs, directories, and personal profile pages later.
Screenshot set
Capture the homepage and one or two important states. Keep filenames dated so they can be tied back to the project state at that time.
Validation notes
Record HTTP status, canonical URL, key links, schema parsing, and sitemap state. A small repeatable check beats a one-off memory.
Case-study summary
Write a short public case study covering the problem, build choices, limitations, and what the project demonstrates technically.
Profile reuse
Use the same evidence-backed wording across profile hubs, source archive copy, CV project sections, and external platform drafts.
A clean public-project loop
The strongest loop is simple: repo links to live site and case study; live site links to repo and case study; main site links to both; profile hub links to the main evidence. The links should feel useful, not forced.
Source proof pack
Use existing source archive surfaces before inventing new ones
The strongest proof surface is usually the one already linked from the project page: a source archive index, a README-style note, a downloadable snapshot, screenshots, and a main-site case study. For SEO and professional visibility, the highest-value work is making those surfaces consistent with the live page rather than scattering the same project across thin duplicates.
First screen context
Open with what the project does, why it exists, current status, live URL, source status, and the safest way to interpret the project.
Description and labels
Use accurate labels and a concise description so visitors can classify the archive quickly: source snapshot, project note, prototype, or maintained reference.
Homepage and social preview
Set the homepage to the live project or canonical case study, and use a preview image that shows the actual project rather than a vague graphic.
Maintenance status
If the project is archived, experimental, private prototype, or in development, say so in the README and the live page.
Canonical choice
Decide which URL is the main reference before publishing
One project can have several public URLs: the source archive, the hosted project page, a custom domain, and a main-site case study. That can be useful, but only if the signals do not fight each other. Pick the main reference for each job and make the links, canonicals, sitemap entries, and profile links support that decision.
Archive as source
Use the archive as the source-code and status record. It should link to the live page and the main-site case study.
Live page as experience
Use the live page to show the project experience, screenshots, public demo, or documentation in a way that works outside the source archive interface.
Main site as context
Use the owned project note for professional context, evidence boundaries, project status, and how the work connects to the wider profile.
Custom domain as identity
Use a custom domain only when the project needs its own durable identity and the DNS, HTTPS, canonical, and Search Console setup can be maintained.
Launch verification
Check the deployed page like a small production site
Source archives can feel informal, but public project proof still deserves a launch check. A broken title, missing canonical, stale project link, or unverified custom domain weakens the proof loop and can leave Google guessing which URL matters.
- Confirm the live page returns `200`, loads over HTTPS, and does not rely on a private login or local-only asset.
- Check title, meta description, canonical URL, Open Graph URL, preview image, and visible H1.
- Confirm the archive page, project hub, case study, and live page link to each other with descriptive anchor text.
- Validate JSON-LD if the page uses WebSite, SoftwareApplication, WebApplication, CreativeWork, Article, or Breadcrumb schema.
- Check whether Search Console, sitemap, or URL Inspection is available for the selected domain or project URL.
- Record the deployed branch, bundle, ZIP, or source snapshot so future edits happen in the version the source archive actually references.
Reference surfaces
Useful references for source archive project proof
These references are worth keeping beside any project handover. Owned source-archive pages explain the local proof surface, while Google canonical guidance explains how consistent signals help search engines choose the preferred URL.
Implementation handoff
Route project proof into audit, launch, and profile assets
Once the source archive and project page are aligned, the next step is to connect the proof into maintained assets: technical SEO checks, launch tools, project case studies, and the source archive.
Technical SEO audit checklist
Use the technical audit when a project page needs canonical, indexing, sitemap, JSON-LD, internal-link, or Search Console checks.
Local website launch checklist
Use the launch tool to turn a project-site release into repeatable preflight, publishing, rollback, and post-launch checks.
John Finnerty source archive
Use the source archive to check project source pages, archive status, safe downloads, README-style notes, and public project positioning.
Project Jaunt case study
Use this case study when the proof is a diagnostic tool, technical workflow, open-source utility, or small public project.
NZ Political Promise Tracker case study
Use this case study when the proof loop depends on source-aware public data, evidence preservation, and careful civic context.
SEO consulting NZ
Use the SEO service page when project proof needs to connect into broader owned-asset strategy, crawl signals, or search measurement.
Professional context
Use project pages to support the wider identity graph
Project notes are strongest when they help a reader verify the person, the source archive, the development reference, and the practical work behind it. That is why the project loop points back to current profile and portfolio pages, not only to code.
Current profile
About John Finnerty gives the public author and technical consulting context for project evidence.
Portfolio hub
The projects page is the central owned hub for project notes, repositories, and case studies.
Example case study
Care Finder Aotearoa shows how a project note can connect source, development references, and careful context.
Local and national relevance
The New Zealand profile helps connect project work to the broader owned presence.
Related services
Project SEO and metadata cleanup
If you are using source archive for a portfolio or small project, the basics matter: canonical URLs, metadata, internal links, and a clear proof loop between the source archive and live site.