SEO Basics for Your Project Website

Most final-year project websites are invisible. Not broken, not ugly — invisible. The team builds a solid project, puts up a site with the demo video and the report PDF, shares the link in the project group, and then nobody outside that group ever finds it. Recruiters Google candidates before interviews. External examiners sometimes search a project title out of curiosity. Students from other colleges search for the exact problem you solved. If Google cannot find your site, all of that discovery goes to someone else's page.

Search engine optimisation for a student project site is not a marketing trick. It is a small set of mechanical practices — title tags, meta descriptions, clean URLs, a sitemap, fast pages — that make your work discoverable by the people already looking for it. This guide covers exactly those practices, in the order of impact, with concrete examples you can copy. Nothing here requires a budget or an SEO tool subscription.

What this guide assumes: you have (or are building) a simple project website — a few pages describing what you built, the tech stack, screenshots or a demo video, and a download link for the report. The examples use plain HTML, but every concept applies identically if your site is built with React, Next.js, or a static site generator.

How Google actually finds your site

Search visibility is a pipeline with four stages. Understanding it tells you which fixes matter and which are noise:

Crawling — Googlebot fetches your pages by following links. If nothing links to your site and you never told Google it exists, crawling may never start. This is the stage most student sites fail at.
Rendering — Google executes the page (including JavaScript) to see the final content. Heavy client-side rendering can delay or break this.
Indexing — Google decides what the page is about and stores it. Thin pages with no real text often get crawled but never indexed.
Ranking — for a given query, Google orders the indexed pages. For a niche project topic with little competition, even basic optimisation is often enough to rank on the first page.

The practical takeaway: for a project site, 80% of the value is in stages 1–3 — being crawled, rendered, and indexed at all. Ranking against serious competition is a longer game you do not need to win; you need to win the query that is literally your project's name and problem statement.

If you are still deciding what to build, the companion guide on how to choose a final-year project topic helps you pick something with a clear, searchable problem statement — which makes every technique below work harder.

The title tag: your highest-leverage 60 characters

The <title> element is the single most influential on-page element you control. It becomes the clickable headline in search results, the browser tab text, and the default label when someone shares your link. Google typically displays roughly the first 50–60 characters before truncating.

A reliable formula for a project page title:

Primary keyword or project name + what it does + your name/college (optional)

Weak title	Why it fails	Stronger title
Home	Says nothing; every site has one	IoT Smart Irrigation System — Final Year Project by Aarav, PCCOE
My Project	Unsearchable	Smart Attendance System using ESP32 and Face Recognition
Final Year Project Website	Generic; matches thousands of pages	Recipe Sharing Platform — MERN Stack Final Year Project
index.html	Sometimes literally the filename	Online Code Editor with Live Preview — React Project

Rules that keep titles working:

Put the most important words first. Truncation cuts from the right, so "Smart Attendance System using ESP32…" survives truncation better than "Final Year Project — Smart Attendance…".
One page, one topic, one title. Your homepage targets the project name; a separate "documentation" or "report" page targets "[project name] documentation" or "[project name] report PDF".
Never duplicate the same title across pages. If every page is titled "My Final Year Project", Google treats them as near-duplicates.
Keep it under ~60 characters. Count them — a title that truncates mid-word looks unfinished in results.

For a project like the student project showcase gallery, a title such as "Student Project Showcase Gallery — Browse Final Year Projects" tells both Google and the visitor exactly what the page offers before they click.

Meta descriptions: the 155-character pitch

The meta description does not directly change your ranking — Google has said as much for years. What it changes is the click-through rate: it is the two-line snippet under your title in search results, your free advertisement for the click.

Write a meta description tag (name="description") with a 150–160 character summary — for example: "Smart attendance system built with ESP32-CAM and face recognition. Marks attendance in under 2 seconds per student. Full source code, circuit diagram and project report included."

Write it like a classified ad, not a keyword list:

Length: aim for 150–160 characters. Longer gets truncated with an ellipsis; much shorter wastes the space.
Include the action: "download the report", "watch the demo", "view source code" — tell the searcher what they get for the click.
Match the page: a description promising a "free download" on a page with no download link produces bounces, and consistent bounces tell Google the result was a poor match.
Unique per page: the same discipline as titles. A site-wide template description ("This is my final year project website") is barely better than none.

A complete <head> for a project homepage, putting titles, descriptions, and the social tags from later in this guide together:

The head section, element by element

Your page head needs six things: the doctype and language attribute, a charset declaration (UTF-8), a viewport tag for mobile (width=device-width, initial-scale=1.0), a title under 60 characters ("Smart Attendance System using ESP32 and Face Recognition"), a meta description of 150–160 characters, and a canonical link pointing at the page's own URL. Get these six right and you have covered 80% of on-page SEO.


## Headings: one H1, in logical order

Headings are the outline of your page, and Google reads them as one. The rules are simple and frequently broken:

- **Exactly one `<h1>` per page**, containing the page's main topic — usually close to the title tag wording.
- **`<h2>` for the major sections** (How it works, Features, Tech stack, Demo video), **`<h3>` for subsections**. Never skip levels (an `<h4>` directly under an `<h1>`), and never use headings for styling — a big bold line of body text should be a `<p>` with CSS, not an `<h2>`.
- Front-load meaning: "How the face recognition pipeline works" beats "Working" as an `<h2>`.

A skeleton that fits most project sites:

This structure does double duty: it is good SEO and it is exactly the structure an external examiner skims when they land on your page. If you are documenting the build in parallel, the guide on writing your final-year project report follows the same logical order — keep the site and the report consistent.

URLs that humans and crawlers can read

Google uses the URL as a weak relevance signal, and humans use it to decide whether a link looks trustworthy before clicking. Both prefer the same thing:

Short, lowercase, hyphen-separated: /smart-attendance-system/ beats /page_id=47 and beats /Final_Year_PROJECT_2026_final_v2/.
Keyword-bearing, not keyword-stuffed: /recipe-sharing-platform/ is good; /recipe-sharing-platform-mern-final-year-project-2026/ is spammy and will look it in every share.
Stable: pick the URL once. Every rename breaks existing links and resets whatever ranking the old URL had earned. If you must change one, add a 301 redirect from the old to the new.

Content: write the page like documentation

Google cannot rank what it cannot understand, and it understands text. The most common reason a project page fails to index is that it contains almost no text: a hero banner, three screenshots, an embedded video, and a download button. To a crawler, that page is nearly empty.

You do not need long-form essays. You need the page to answer, in text, the questions a visitor has:

What does it do? One plain-language paragraph. No jargon in the first two sentences.
What problem does it solve? Two to four sentences of context — who has this problem today.
How does it work? The pipeline in 4–6 steps, naming the actual components and technologies.
What is the tech stack? A list with one line each on why it was chosen.
How do I run it? Prerequisites, install commands, and the expected result. This section alone often doubles a page's useful text.
What did you learn / what are the limitations? Honest limitations ("works reliably within 3 metres in indoor lighting") build more trust — and more distinctive, quotable text — than a features list alone.

A page covering those six sections naturally lands in the 800–1500 word range, which is plenty for a niche topic. Do not pad it; a thin page with real information outranks a long page of filler for the specific queries that matter to you.

Images need text too. Every meaningful image gets an alt attribute describing what it shows: alt="Wiring diagram: ESP32-CAM connected to FTDI programmer and 5V supply" — not alt="image1". Alt text is what Google Images indexes, and it is what screen readers announce. Decorative images (backgrounds, dividers) get an empty alt="" so assistive tech skips them.

Speed: the ranking factor you can measure today

Page speed is a confirmed ranking signal, and for project sites it is usually the easiest technical win because the typical culprits are obvious: a 6 MB hero image, five unminified libraries, no caching. Google's Core Web Vitals define the thresholds that matter:

Metric	What it measures	"Good" threshold
LCP (Largest Contentful Paint)	How fast the main content appears	≤ 2.5 seconds
INP (Interaction to Next Paint)	How fast the page responds to clicks/taps	≤ 200 milliseconds
CLS (Cumulative Layout Shift)	How much the layout jumps while loading	≤ 0.1

The fixes, in order of impact for a typical student site:

Shrink your images. Export photos as WebP at the display size (a 1600 px-wide hero rarely needs to be 4000 px), and compress them. A hero image should be well under 300 KB; thumbnails under 100 KB. This single step often halves load time.
Set image dimensions. Always include width and height (or aspect-ratio CSS) on images so the browser reserves space — this kills most layout shift (CLS).
Lazy-load below-the-fold images with loading="lazy" on every <img> that is not visible on first paint.
Cut what you do not use. That animation library imported for one effect, three font weights when you use one, the analytics snippet plus two more trackers — remove them. Fewer requests beats clever optimisation.
Serve over HTTPS and enable compression. Most student hosting (GitHub Pages, Netlify, Vercel) gives you both by default; if yours does not, that is a reason to move.

Measure with PageSpeed Insights (free, from Google) before and after. Aim for the green "Good" band on mobile — Google predominantly uses the mobile version of your page for indexing, so test the phone viewport, not your laptop.

The two files that introduce you to Google: robots.txt and sitemap.xml

robots.txt lives at your domain root and tells crawlers which parts of the site they may fetch. For a project site it is usually permissive:

User-agent: *
Allow: /

Sitemap: https://aarav-projects.example/sitemap.xml

Only disallow paths with a reason — /admin/, staging subdomains, or generated junk pages. A common self-inflicted wound is Disallow: / left over from development, which tells Google to ignore the entire site. Check yours.

sitemap.xml is the explicit list of your pages. It does not guarantee indexing, but it guarantees Google knows the pages exist, which is the entire battle for a new site with few inbound links:

A minimal sitemap is an XML file listing each page URL with its last-modified date and change frequency. For a three-page project site it has three entries: the homepage, the attendance-system page, and the recipe-platform page, each with a lastmod date. Generate it by hand or with a static-site plugin, then submit it in Search Console.

Keep it honest: list only real, public pages (no login-walled or staging URLs), keep it under 50,000 URLs (you will have a dozen), and update lastmod when a page actually changes.

Then tell Google directly. Create a free Google Search Console property for your domain, verify ownership (DNS record or HTML file), and submit the sitemap under Sitemaps. Within days you will see which pages are indexed and, critically, which were crawled but excluded — with reasons like "Discovered – currently not indexed" that tell you exactly what to fix.

Verify the basics yourself from the terminal before submitting:

curl -s -o /dev/null -w "%{http_code}\n" https://aarav-projects.example/robots.txt
curl -s -o /dev/null -w "%{http_code}\n" https://aarav-projects.example/sitemap.xml

Both should return 200. And a quick Python check that every URL in your sitemap actually resolves:

import requests, xml.etree.ElementTree as ET

xml = requests.get("https://aarav-projects.example/sitemap.xml", timeout=15).text
urls = [u.text for u in ET.fromstring(xml).iter("{http://www.sitemaps.org/schemas/sitemap/0.9}loc")]
for u in urls:
    r = requests.head(u, timeout=15, allow_redirects=True)
    print(r.status_code, u)

Anything that is not a 200 here is a page you are asking Google to index that does not exist — fix the sitemap or restore the page.

Internal linking: the crawler's road map

Google discovers pages by following links, and your own site's links count. A project site with five pages and no links between them forces the crawler to find each page independently; a site where every page links to the related ones gets crawled thoroughly in one visit.

Practical internal linking for a project site:

From the homepage, link every project with descriptive anchor text: "Smart attendance system using ESP32" — not "click here", not "Project 1".
From each project page, link to the 1–2 most related projects ("If this interests you, see the recipe sharing platform for a full-stack web project in the same portfolio").
Link your report PDF and demo video from the project page with text around them, so the crawler has context for what those assets are.
Add a simple footer or "All projects" index page — one page that links to everything guarantees no page is more than one click from the homepage.

The online code editor with live preview project is a good model here: a single-page tool whose documentation page links outward to the concepts it demonstrates, giving crawlers a clear path in both directions. More web project ideas in this space are collected in the Web Development branch hub.

Social cards: Open Graph tags

When your link is shared on WhatsApp, LinkedIn, or X, the preview card — title, description, image — comes from Open Graph tags, not from your SEO tags. A missing og:image means a grey box; a good one measurably increases click-through on shares, which is how project links actually spread among students.

The four tags that matter:

For link previews, add Open Graph tags: og:title (the project name), og:description (one compelling sentence), og:image (an absolute URL to a 1200×630 preview image), and og:url (the canonical page URL). WhatsApp, LinkedIn and Twitter all read these.

Use an image at least 1200×630 px, under 1 MB, that reads at thumbnail size — a clean project screenshot or photo, not a logo on white. Test the card with each platform's validator (LinkedIn Post Inspector, X Card Validator) before you start sharing the link.

Measuring: what to watch in Search Console

After 2–4 weeks, Search Console's Performance report answers the only three questions that matter:

Question	Where to look	Healthy sign for a new project site
Is Google showing my pages?	Impressions per page	Impressions climbing from zero within 2–3 weeks of sitemap submission
Are people clicking?	Click-through rate (CTR)	2–5% on branded queries (your project name); lower on generic ones is normal
Which queries bring visitors?	Queries tab	Your project name and problem-statement phrases appearing

Do not chase vanity metrics in month one. A new site ranking #3 for its own project name with 40 impressions a month is working — that is 40 people who found your work instead of nothing. The compounding comes from every project you add following the same template.

Diagnosis table: why your site is not showing up

Symptom	Likely cause	Fix
Site not in Google at all after a month	Never submitted; no inbound links; `Disallow: /` in robots.txt	Submit sitemap in Search Console; check robots.txt returns 200 and allows crawling
Homepage indexed, project pages missing	No internal links to them; thin content	Add descriptive links from homepage; ensure each page has real text sections
Pages crawled but "not indexed"	Thin or duplicate content	Rewrite with the six documentation sections above; unique titles per page
Title in results differs from your title tag	Title too long, stuffed, or missing	Rewrite to ~55 characters, front-load the keywords
Good content, still no impressions	Site is new; no external links	Share in relevant communities; link from your GitHub README and LinkedIn
Images not appearing in image search	Missing/meaningless alt text; images blocked by robots	Descriptive alt text; check images are crawlable
Mobile usability errors in Console	Viewport meta missing; tiny tap targets	Add viewport meta; minimum 48 px tap targets; retest

Pre-launch SEO checklist

Run through this once per site, and the short version per new page:

Every page has a unique <title> under ~60 characters, keywords first.
Every page has a unique meta description of 150–160 characters with a clear call to action.
Exactly one <h1> per page; headings in logical order, none used for styling.
URLs are short, lowercase, hyphenated, and stable.
Each project page answers what / problem / how / stack / run-instructions / limitations in text.
All meaningful images have descriptive alt text and explicit dimensions; below-fold images lazy-load.
Hero image under ~300 KB as WebP; PageSpeed Insights mobile score in the green.
HTTPS live; viewport meta present; no horizontal scrolling on a phone.
robots.txt allows crawling and references the sitemap; both return 200.
sitemap.xml lists only real public pages; submitted in Search Console.
Every page is reachable within one click from the homepage via descriptive link text.
Open Graph tags present with a 1200×630 preview image; card tested on one platform.

Putting it together

SEO for a project website is a checklist, not a campaign. Title, description, headings, real text, fast images, a sitemap, and internal links — done once per site and ten minutes per new page — are the difference between a portfolio that Google can show people and one it cannot see. Start with the title tags and the sitemap submission this week; they are the two moves with the highest return for the least effort. Then, as you document each project properly, you are simultaneously building the content that earns the clicks — the same honest, specific writing that makes a project page useful to a visitor is what makes it rankable in the first place.

SEO Basics for Your Project Website: Title Tags, Meta Descriptions, Sitemaps and Speed