Start with a crawlable structure
I do not start technical SEO with a keyword list. I start by asking whether a visitor and a crawler can reach the important pages without guessing. A stable route structure, normal links and a useful hierarchy do more for a small site than a pile of disconnected optimizations.
For this portfolio, projects, articles, categories and topics are separate resources. That gives each page a job and creates natural paths between them. A case study can point to a technical topic, and an article can point back to the project where the lesson came from.
- One canonical URL per piece of content
- Descriptive titles and meta descriptions
- Internal links between articles, projects and topics
Choose the rendering strategy deliberately
Next.js gives several ways to render a page, but SEO is not improved just because a framework supports server rendering. The useful question is whether the first response contains the content a user came for. Pages that do not need live data are good candidates for static generation; interactive details can stay on the client.
I also check the generated HTML rather than trusting the component source. A page can look correct after JavaScript runs while still sending an incomplete first response. That distinction matters for crawlers, link previews and people on a slow connection.
- Keep important content in the initial response
- Do not fetch the article title only after hydration
- Use client components for interaction, not for the whole page
Make metadata match the page
Every route needs a title and description that describe that route, not a recycled slogan. The homepage introduces the person, a project page explains a project, and an article answers a technical question. Repeating the same metadata across all three makes the site harder to classify.
Canonical URLs are equally important when a page can be reached through multiple paths. I generate them from the stable route and keep the site URL in one place. Open Graph metadata then makes shared links readable without pretending it is a ranking shortcut.
- Write metadata from the page intent
- Set canonical URLs on indexable pages
- Use Open Graph data for human-readable previews
Use structured data as supporting context
JSON-LD is useful when it describes facts already visible on the page. On an article, that means the headline, author, dates, URL and topics. On the site, it means connecting the person, the website and the journal. I avoid adding properties only because a schema example contains them.
The goal is clarity, not guaranteed rich results. Structured data cannot rescue a thin article or a confusing navigation system. It can, however, reduce ambiguity about who wrote a page and what kind of resource it represents.
- BlogPosting and BreadcrumbList schemas
- Person and WebSite schemas
- Validate JSON-LD after rendering
Measure the experience
A technically crawlable page can still be unpleasant. I review image weight, JavaScript, layout stability and the time before the main content becomes useful. For a portfolio, a small client-side footprint and correctly sized images are usually more valuable than another animation.
My final check is always made on the actual routes. I look at the page source, test navigation with JavaScript disabled when possible, and run the production build before calling the SEO foundation finished.