How to Build a Developer Portfolio Website That Actually Gets You Hired

This site is the fourth version of my portfolio. The first three got me almost nothing; this one brings in remote client work every month and ranks for the searches I actually want. The difference was not design. It was treating the portfolio as a product with two users, a hiring manager and Google, and building for what each of them needs. Here is that checklist, with the specific decisions behind shawab.space.

Two users, thirty seconds each

A hiring manager or agency owner opens your portfolio from a LinkedIn message, a job application or a search result. They are deciding whether to spend five more minutes. In that first screen they need:

1. What you do, in one sentence that names a role and a stack. "Full-stack developer specialising in WordPress, PHP and React" beats "I build digital experiences."
2. Proof: a number, a client, a result. "7+ years, 100+ projects, currently at UMM Digital" is the version on my home page.
3. A next step: a contact button that works, and a hire-me page that explains how you engage.

Google, meanwhile, is deciding whether your page answers a query. It needs the same clarity in machine-readable form: a title tag, a description, headings that say the same thing, and structured data that names you as a Person with a jobTitle and a location.

The pages that matter

Single-page portfolios with anchor links lose on both fronts: one URL can only rank for one intent, and a hiring manager cannot send a colleague a link to "the case studies". This site's services, hire-me and about pages exist for exactly that reason.

The case study format

A thumbnail says "I made a website". A case study says "I solved a problem under constraints and measured the result", which is what anyone hiring a senior developer is buying. The format I use:

## [Client or project name] — [one-line result]

**Context.** Who they are, what they had, why it was a problem. (2–3 sentences)
**Constraints.** Budget, timeline, legacy systems, team. This is where seniority shows.
**Decisions.** The 2–3 technical choices that mattered and *why*. Include the option you rejected.
**Build.** Stack, architecture diagram if useful, the hard part.
**Result.** Numbers: load time, conversion, revenue, hours saved, Lighthouse before/after.
**What I'd do differently.** One honest paragraph. Reviewers trust this more than the rest combined.

Numbers do not need to be huge. "Reduced product page LCP from 3.1 s to 1.7 s; mobile conversion +11%" from a small store is more convincing than "built a scalable platform" with no figure. If you cannot share a client's name, describe the industry and size; if you cannot share numbers, share relative improvements.

Technical SEO checklist

Per-page metadata

<title>Shawab Khan | Full-Stack Developer (WordPress, PHP, React)</title>   <!-- under 60 chars, role + stack -->
<meta name="description" content="Remote full-stack developer with 7+ years and 100+ projects. Custom WordPress themes, React front-ends, AWS deployments. Available for freelance and contract work.">   <!-- 150–160 chars, includes availability -->
<link rel="canonical" href="https://shawab.space/">
<meta property="og:title" content="…"><meta property="og:description" content="…"><meta property="og:image" content="https://shawab.space/og/home.png">
<meta name="twitter:card" content="summary_large_image">

Every page gets its own title and description. If your framework hard-codes them in a shared header (as an earlier version of this site did), fix that first; a portfolio where every page has the same title is telling Google there is only one page.

Structured data

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://shawab.space/#person",
      "name": "Shawab Khan",
      "jobTitle": "Full-Stack Web Developer",
      "url": "https://shawab.space",
      "image": "https://shawab.space/images/shawab-khan.jpg",
      "address": { "@type": "PostalAddress", "addressLocality": "Aligarh", "addressRegion": "Uttar Pradesh", "addressCountry": "IN" },
      "worksFor": { "@type": "Organization", "name": "UMM Digital" },
      "alumniOf": { "@type": "CollegeOrUniversity", "name": "Aligarh Muslim University" },
      "knowsAbout": ["WordPress", "PHP", "React", "Next.js", "AWS", "MySQL", "Docker", "Nginx"],
      "sameAs": ["https://github.com/Shawabkhan", "https://www.linkedin.com/in/cyberwarriorshawab"]
    },
    {
      "@type": "WebSite",
      "@id": "https://shawab.space/#website",
      "url": "https://shawab.space",
      "name": "Shawab Khan — Portfolio",
      "publisher": { "@id": "https://shawab.space/#person" }
    },
    {
      "@type": "ProfessionalService",
      "name": "Shawab Khan — Web Development Services",
      "url": "https://shawab.space/services",
      "provider": { "@id": "https://shawab.space/#person" },
      "areaServed": "Worldwide",
      "serviceType": ["WordPress Development", "React Development", "Full-Stack Development"]
    }
  ]
}

The @id references let every blog post's author and every case study's creator point at the same Person entity, which is how Google builds a knowledge-graph picture of you rather than seeing disconnected pages. Validate with the Rich Results Test after every change.

The rest of the checklist

• Clean URLs (/blog/post-slug, not /blog.php?id=7), one canonical per page, HTTPS everywhere with a single redirect from www/http.
• XML sitemap generated from the same data that renders the pages, submitted in Search Console; robots.txt that references it.
• Internal links: every blog post links to a service or hire-me page; every case study links to the relevant posts. Link text should say what the target is about.
• Images: descriptive filenames, alt text, explicit dimensions, AVIF/WebP, lazy below the fold. Your headshot should have your name in the alt.
• Open Graph images per page. A LinkedIn share with a blank preview is a lost click.
• An llms.txt at the root: a plain-text summary of who you are and your key pages. AI assistants increasingly read it, and it costs five minutes.

Your portfolio is a performance demo

A technical reviewer will open DevTools. If a portfolio claiming "performance-focused" ships 1.8 MB of JavaScript and fails CLS, the claim is dead. Hold yourself to the budget you would set for a client:

• Lighthouse 95+ on mobile for every page; Core Web Vitals green in the field once you have traffic.
• Under 100 KB of JavaScript on the home page. This site uses HTMX for navigation and a few hundred lines of vanilla JS; see why I chose that over React here.
• Fonts self-hosted or preconnected, with a metric-matched fallback so there is no layout shift.
• Hosting behind a CDN. The Core Web Vitals field guide has the full process.

Write, because it compounds

The single best thing I did for this portfolio was start publishing technical articles. Each one targets a real search query, demonstrates how I think, and gives a hiring manager something substantive to read after the 30-second scan. Six months of posts now bring more qualified traffic than every other page combined, and the posts a client reads before contacting me pre-answer the questions a first call used to spend an hour on.

Practical rules: write about problems you actually solved, include code and numbers, aim for the long-tail query a developer would type when stuck, and link every post to the page where someone can hire you. Quality over cadence; one strong post a month beats four thin ones. The blog index on this site has the search, category filters and structured data that make a growing archive navigable for both users and crawlers.

Conversion: make it easy to say yes

• A contact form that works and an email address in plain text for people who hate forms. Test it monthly.
• Availability stated plainly: "Available for remote contract work from [date]" or "Booked until [month]". Vague availability reads as unavailable.
• How you work: engagement models (hourly, project, retainer), time zone overlap, tools. My hire-me page is essentially an FAQ that removes reasons to hesitate.
• Social proof that can be verified: named clients with permission, LinkedIn recommendations, a GitHub with real activity.
• Response time: reply to inbound within a day. The portfolio's job is to get the message; yours is to answer it.

That is most of the gap between a portfolio that exists and one that works. The rest is consistency: another case study when a project ships, another article when you learn something, and the same care for your own site that you give to clients'. If you are building a remote career from outside the usual tech hubs, this is the longer story of how it worked for me.