A few weeks ago I ran a Lighthouse audit on my own portfolio, lakshmiunni.com, expecting a decent score. Instead I got a 53 — mobile performance, barely passing. That number is what pulled me into on-page SEO properly, instead of treating it as something separate from the front-end work I already do every day.
Chasing that number down — and everything that came with it — changed how I think about my own work. On-page SEO isn’t a separate skill I need to learn on top of front-end development. It’s mostly the same skill, just measured by a different scorecard. Title tags, heading structure, image descriptions, internal links, Core Web Vitals — I was already making these decisions on every page. I just wasn’t making them with search engines in mind.
Here’s the checklist I now run through on every page I build, with real examples from my own site and a simple “how to check” step for each one using Chrome DevTools — free, already installed, no plugins needed.
Title Tags and Meta Descriptions
I used to think of the title tag as a formality — whatever text felt natural to type into WordPress. Then I looked at how Google actually displays it: that blue clickable link in search results, with a gray summary line underneath (the meta description). Neither one shows up on the page itself. But together, they’re often the whole reason someone clicks my result instead of a competitor’s.
The mistake I catch myself making isn’t creative, it’s technical — accidentally reusing the same title across pages, or writing one so long that Google just cuts it off mid-sentence. I learned Google actually truncates based on pixel width, not character count, which is why two titles with the same letter count can display completely differently — wide letters like “W” and “M” eat up space faster than narrow ones like “i” or “l.” I just aim for roughly 50-60 characters and stop overthinking the pixel math.
On my own site, I made sure every page has its own unique title instead of sharing one generic one across the whole site. It felt like a small decision at the time, but it means each page can actually target something different in search.
How I check it: I open DevTools (F12), find the section showing the page’s title and description, and confirm each page has its own. If a page is missing a description entirely, or it matches another page’s, I know I’ve got a fix to make.
H1–H3 Heading Hierarchy
This one embarrassed me a little when I first looked closely. Search engines read heading levels the way I’d read a table of contents — they use the structure to understand what a page is actually about. Google has actually said multiple main headings won’t hurt rankings, but I still stick to one clear main heading per page, then sub-headings for major sections, and smaller headings nested under those — it’s not a strict rule, but it keeps the page unambiguous for both search engines and screen readers.
My honest mistake, early on: choosing heading sizes based on how I wanted the text to look, not what it meant structurally. A small caption styled like a big heading because it “looked right” against the design. Skipping a level because that’s what matched the layout I had in mind. Search engines — and screen readers, which matters just as much — read the order, not just the visual size.
On my homepage now, the structure is deliberate: one clear main heading up top, followed by section headings for each major part of the page — Featured Projects, Skills, Blog. Nothing skips a level anymore.
How I check it: In DevTools, I search through the page structure for each heading level and confirm there’s exactly one main heading, and that everything below it is ordered logically, top to bottom.
Image Descriptions (Alt Text)
This is the one that’s easiest to get wrong without ever noticing, because a missing image description doesn’t break anything visually. The page looks completely fine. It’s only invisible to screen readers and search crawlers — neither of which can actually “see” an image the way I can.
I went through my own site and rewrote every image description to be genuinely descriptive instead of generic or blank. My profile photo describes who it is, not just “profile picture.” My project screenshots describe what’s actually shown — a specific dashboard or app, not just “screenshot.”
It surprised me how much this overlaps with accessibility work. Fixing it for SEO basically fixed it for accessibility too, at the same time, for free.
How I check it: I run Chrome’s built-in Lighthouse tab under the Accessibility section — it automatically flags every image on the page that’s missing a proper description, so I don’t have to check each one by hand.
Internal Links
I didn’t think much about internal linking until I noticed how isolated some of my own pages were — technically live, technically fine, but nothing else on the site pointed to them. Internal links are what help search engines understand how your pages relate to each other, and they’re what keep a visitor moving instead of leaving after one page.
I fixed this on my own Core Web Vitals post — it now links back to my case studies and my projects page, so someone interested in performance work has an obvious next step instead of hitting a dead end.
How I check it: I open the page and scan through it for links pointing back to other pages on my own site, and just count them. I aim for at least 2-3 per blog post. Zero is a sign I left something unfinished.
Core Web Vitals Basics
This is the section I learned the most from, because it’s where I was genuinely wrong at first.
Core Web Vitals are three metrics Google uses to measure real page experience, each with a “good” threshold: Largest Contentful Paint (LCP) — how long the biggest visible thing on the page takes to load (good: under 2.5s), Cumulative Layout Shift (CLS) — how much content jumps around while loading (good: under 0.1), and Interaction to Next Paint (INP) — how responsive the page feels across every interaction, not just the first click (good: under 200ms). INP replaced an older metric called First Input Delay back in March 2024, so if you ever read an SEO guide still mentioning FID, it’s outdated.
My homepage’s LCP started at 5.8 seconds — solidly “poor.” My first instinct was to blame my profile photo, so I made it load earlier on the page. It didn’t help at all — LCP actually got worse, up to 6.6 seconds. That result told me my first guess was wrong. The real cause turned out to be something I hadn’t even considered: a scroll-in animation on my stats section (the “3+ Years, 5 Companies, 90%” numbers) that kept that text invisible for almost two full seconds — even though it sits right at the top of the page, with nothing for a visitor to scroll down and “reveal.” I was hiding content that was already in view.
Turning off that one animation — and leaving it everywhere else on the page where it actually made sense — dropped my LCP from 6.6s to 3.6s and pushed my Lighthouse Performance score from 67 to 84.
The lesson stuck with me: don’t guess at what’s slow. Measure it, then measure again after you think you’ve fixed it, because your first guess is often wrong.
How I check it: I open DevTools, click Lighthouse, select Mobile, and run Analyze page load. Then I look for the section that breaks down exactly what’s contributing to my LCP time — it shows which element Google is actually measuring, and where the delay is really coming from. That breakdown is what showed me my real problem wasn’t the image at all.
Conclusion
I used to treat on-page SEO as something bolted onto development after the “real” work was done. Now I see it as the same work, just read differently — a missing image description, an animation hiding content that’s already visible, a title a few characters too long. These are small decisions with real consequences for whether anyone finds the page at all.
If you want the full story behind the Core Web Vitals fix — the exact steps and before/after numbers — I wrote it up in detail here: How Core Web Vitals Directly Affect Your Search Rankings.
Want to see this checklist applied to a full production project, not just a personal portfolio? Read the Case Study →
Looking for a front-end developer who thinks about SEO and performance from day one? Get in touch →