How I Built a Recruiter-Focused Next.js Portfolio with SEO and Proof Pages

A portfolio should be more than a polished landing page. For a developer, it needs to answer a practical hiring question quickly: who is this person, what kind of work do they do, and where is the proof?

That was the direction behind the latest version of waxifalee.com. I wanted the site to connect my real name, Wasif Ali, with the online handle I use in public technical spaces, WaxifAlee. I also wanted the portfolio to be easier for recruiters, founders, engineering managers, and other developers to scan without turning it into a keyword-stuffed resume page.

This post explains the structure I used: technical SEO, canonical URLs, project proof pages, recruitment-intent pages, internal links, cleaner resume positioning, and a database-backed blog foundation for future writing. It is not a claim that the site now ranks for broad recruitment keywords. SEO takes time, and the useful work starts with making the site clear, crawlable, and honest.

The problem with generic developer portfolios

Many developer portfolios look good at first glance but do not make hiring easier.

They often have a hero section, a list of technologies, some project cards, and a contact button. That is a reasonable start, but it can leave important questions unanswered:

• What role is this person targeting?
• Which projects prove the skills being claimed?
• Is the site about a real person or just a template?
• Can a recruiter find the CV, projects, and contact path quickly?
• Can search engines understand the identity and page structure?

I did not want waxifalee.com to depend only on visual polish. The site needed to show role clarity, technical proof, and a stable personal identity.

Defining the identity

The first decision was simple but important: the site needed to consistently connect Wasif Ali and WaxifAlee.

The real name matters because hiring, resumes, and professional references usually happen around a real identity. The handle matters because it is part of the public developer brand and is tied to the domain, waxifalee.com.

Instead of treating those as separate identities, the site now uses both together where it is natural:

• Wasif Ali as the professional name
• WaxifAlee as the online identity
• waxifalee.com as the canonical home for both

That also influenced the SEO setup. Canonical URLs, structured data, Open Graph metadata, and internal links all point back to the same domain and identity instead of splitting signals across temporary deployment URLs or inconsistent names.

Technical SEO foundation

Technical SEO is not magic. For this portfolio, it mostly meant removing ambiguity.

The site uses a single canonical domain:

https://waxifalee.com

That domain is used for canonical URLs, sitemap entries, robots.txt, Open Graph URLs, Twitter preview metadata, and JSON-LD identifiers. The goal is straightforward: search engines and social platforms should see the same preferred URL everywhere.

The foundation includes:

• canonical URLs for public pages
• a sitemap with canonical routes only
• robots.txt pointing to the canonical sitemap
• page-specific metadata instead of one generic title everywhere
• structured data for the person and website where it matches visible content
• social preview metadata using the site brand
• a not-found page that is not meant to be indexed

None of this guarantees rankings. It simply gives the site a cleaner technical base and avoids common mistakes such as stale Vercel URLs, duplicate canonical signals, or metadata that does not match the page.

Proof pages over keyword stuffing

It is tempting to repeat phrases like software engineer, full stack developer, backend developer, and fintech engineer across a portfolio and hope that search engines understand the page.

That is not the approach I wanted.

A recruiter or engineering manager needs proof, not repetition. That is why the projects section became more important than generic keyword density. Project pages can explain the kind of problems I work on, the technical areas involved, and the constraints behind the implementation.

The current direction is to make project pages answer questions like:

• What was the purpose of the project?
• What technical responsibilities were involved?
• Which stack or system concerns mattered?
• What does this prove about the way I build software?

That is more useful than repeating a job title in every paragraph. It also gives internal links a real purpose. Instead of forcing keywords, role pages can point to project evidence where the context supports it.

Recruitment-intent pages

I added focused role pages for the kinds of searches and hiring conversations that are most relevant to the portfolio:

• Full Stack Developer
• Backend Developer
• Fintech Software Engineer

These pages are not doorway pages. They need to be useful on their own and consistent with the rest of the site.

The full stack page gives a broader view of product and web delivery. The backend page focuses more on APIs, data, PostgreSQL, Go, and system boundaries. The fintech page gives a route for fintech-oriented engineering context without inventing private metrics, client details, or compliance claims.

The important part is restraint. I did not create every possible keyword page. A portfolio does not need a page for every framework or role label. It needs a few pages that match real experience and can link naturally to supporting proof.

Cleaner resume positioning

The CV page is part of the same system. It should support the site, not compete with it.

The portfolio pages help explain the narrative: identity, role focus, projects, and contact paths. The CV gives a more direct professional summary for someone who wants the resume-style view.

That is why the internal paths matter:

• project proof lives under Projects
• role context lives under the recruitment-intent pages
• resume context lives under CV
• the hiring or collaboration path goes through Contact

This makes the site easier to scan. A recruiter does not have to guess where to go next, and search crawlers can follow a clearer relationship between pages.

Future blog architecture

The blog foundation is intentionally careful.

I did not want to add fake posts, placeholder articles, a rushed admin dashboard, public comments, likes, or view counters. The first step was a database-backed structure that can support real writing later:

• draft and published post states
• tags
• authors
• per-post SEO metadata
• canonical URLs
• Open Graph and Twitter metadata
• BlogPosting JSON-LD for published posts only
• RSS
• sitemap integration
• safe Markdown rendering
• reading time

The empty blog is also handled deliberately. If there are no published posts, the blog page should not pretend there is content and should not be treated as an indexable thin page. That is better than publishing filler just to make the navigation look complete.

What I would do differently

If I were starting again, I would separate the content strategy earlier from the visual redesign.

It is easy to spend time on layout before the site has answered the harder questions: who is this for, what should it prove, and how should someone move from first impression to evidence?

I would also set up measurement earlier. Search Console data, indexing behavior, and real query impressions will matter more than assumptions. The current structure is a foundation, not a victory lap. Future changes should be based on what people search for, what pages they land on, and where the site still feels unclear.

SEO is iterative. A clean technical setup helps, but it does not replace useful content, real proof, or patience.

Closing

The goal of waxifalee.com is to make the connection between Wasif Ali and WaxifAlee clear, professional, and useful.

For recruiters and engineering teams, the best next step is to review the projects, scan the role-focused pages for full stack, backend, and fintech engineering, or view the CV.

If the work looks relevant, you can contact me here.