Public Source Archive SEO Checklist
Titles, canonicals, structured data, sitemaps, and a clean link graph, plus the small things that help the site get crawled consistently (and not treated as a throwaway).
Reading path
public source archive SEO and proof
A practical order to publish a project site on source archive with clean URLs, useful metadata, and evidence that helps people (and search engines) understand what the project is.
Start here
Make one canonical page that explains the project
public source archive pages often fail to rank because they do not clearly answer: what is this, who is it for, and where is the maintained reference. Start by making a single page that stands alone, then link out to the repo, project notes, and related resources.
Projects hub
A useful pattern is: short project summary (hub), detailed case study (main site), and a live proof page (source archive) that points back to the maintained write-up.
Use the path
Connect the live page, repository, and project notes
A public source archive page works best when it is not isolated. The live page should explain the project in plain language, the repository should show source and maintenance context, and the main site should hold the broader case study or project note.
Live page
Use one clear canonical URL, a useful title, a short project summary, and visible links to the repo and project context.
Repository
Keep the README, topics, homepage field, and project status aligned so visitors know whether the work is active, archived, or experimental.
Main-site context
Use a case study or project note to explain the problem, constraints, design decisions, and evidence without overclaiming adoption.
Search checks
Check sitemap coverage, canonical URLs, crawl status, and snippets after launch rather than assuming source archive alone will carry the signal.
Canonical proof
Choose the URL you want people and search engines to treat as the main reference
source archive can create several useful URLs for one project: the repository, the former hosted project page, a custom domain, and a main-site project note. The job is to make those URLs reinforce each other instead of looking like disconnected copies.
Pick canonical URL
Set repo homepage
Link back to case study
Use matching schema
Verify crawl state
Default Pages URL
Use the hosted project URL when the project is a lightweight proof page and the repo itself is the strongest source-of-truth.
Custom domain
Use a custom domain when the project needs a durable public identity, then make the canonical, Open Graph URL, sitemap entry, and repo homepage agree.
Main-site project note
Use the main site for the broader case study, limitations, screenshots, and professional context. Link back to the live proof page and repository.
Repository README
Use the README to state current status, live URL, setup notes, and limitations. Keep the language consistent with the live page and case study.
Owned proof loop
Connect source archive proof to the profile, projects, and SEO checks
A public source archive page is strongest when it sits inside a clear proof loop: profile page, repository, live page, main-site project note, and a small technical SEO checklist. That gives people several ways to verify the work without turning a project note into a sales page.
John Finnerty source archive
Keep repositories, pinned projects, homepage fields, and README status notes aligned with the live proof pages and main-site case studies.
Care Finder Aotearoa case study
Use careful project notes to explain purpose, constraints, screenshots, and development context without overstating availability or adoption.
Project Jaunt case study
Use a case study when the useful proof is process, diagnostics, architecture, or a small tool rather than a broad public launch.
Technical SEO audit checklist
Check title, description, canonical, JSON-LD, sitemap, image, internal links, and crawl state before treating a project page as finished.
Local website launch checklist
Use the launch checklist to turn a small proof page into a repeatable release with preflight, publishing, and post-launch checks.
SEO consulting NZ
Use the service page when the project proof needs to connect into broader site structure, search measurement, and owned-asset planning.
Next
Treat it like a real launch, even if the audience is small
Launch discipline is what makes a small site feel trustworthy: working forms, correct canonicals, analytics, and a rollback plan. The goal is not hype. It is a clean, checkable record that you can keep improving.
Website Launch Checklist for SME NZ
A release checklist that still applies to project sites: redirects, sitemap coverage, internal links, analytics, and post-launch checks.
About John Finnerty
If the project site represents you professionally, connect it back to a stable profile page and keep the claims careful and current.
Proof and safety
Use source archive settings as part of the evidence trail
A project site is more credible when the repo, live page, DNS, and HTTPS settings agree. Source archive's own Pages documentation covers custom domains, HTTPS enforcement, and domain verification. For a public project proof page, those settings are not just technical hygiene; they show that the page is intentionally maintained.
Custom domain
Record whether the Pages site uses the hosted project URL or a custom domain, then make the canonical URL match that decision.
HTTPS
Check HTTPS enforcement and mixed-content warnings before treating the page as a public proof asset.
Domain verification
If a custom domain is involved, keep the verification and DNS notes with the project handover so ownership remains clear.
Search proof
Save the live URL, repository URL, title, canonical, sitemap status, and last deployment note so future updates are easy to audit.
Official references
Use official docs for the parts that change over time
source archive settings, Google canonical handling, and structured-data expectations can change. Keep the project handover tied to official references instead of relying on old blog posts or remembered setup steps.
source archive domains
Use the source archive deployment notes when deciding whether the proof page should stay on the source archive URL or move to a custom domain.
Profile README
Use the source archive profile notes when the project is part of a profile-level proof loop.
Canonical URLs
Use Google Search Central's canonical guidance when choosing between project page, hosted project URL, and main-site case study.
Structured data
Use Google's structured-data introduction to keep schema useful, parsable, and aligned with what the page visibly says.
Support
When source archive is part of a bigger handover problem
Sometimes the real issue is not source archive. It is DNS control, email delivery, or an undocumented provider change. If the project site depends on a domain you do not fully control, fix that foundation first.
DNS and email checklist
Ownership, record mapping, SPF/DKIM/DMARC, and a handover plan that avoids mystery changes.
Routing and DNS support
When the issue is not the HTML at all: DNS routing, provider handover, or a broken redirect chain.