I Didn’t Rebuild My Portfolio to Look Better. I Rebuilt It to Be Found

A portfolio is often treated as a visual résumé: a polished landing page, a few project cards, and a contact link.

I wanted mine to do more.

This rebuild was about turning my portfolio into a durable professional platform. One that clearly communicates my work to recruiters and collaborators, remains easy to maintain as my work grows, performs well on real devices, and gives search engines and AI-assisted search systems enough structure to understand what I do.

The result is a portfolio centered on writing, projects, research, and professional experience with a CMS-backed architecture, structured SEO, an AI portfolio assistant, and production performance monitoring.

The Goal: Something More than Visual Appeals#

The previous version of my portfolio was highly visual and animation-driven. It represented a particular stage of my work well, but over time I wanted something more focused, calmer, and easier to evolve.

The question guiding this rebuild was:

Can a personal portfolio behave more like a professional knowledge base than a static showcase?

That meant optimizing for several audiences at once:

• Recruiters who need to understand my profile quickly.
• Technical readers who want to explore my work and writing.
• Collaborators who want evidence of depth across software architecture, web engineering, AI, and research.
• Search engines that need clear semantic structure.
• AI-assisted search tools that rely on crawlable, structured, sourceable web content (GPT, Gemini, or Claude).

The visual redesign was only one layer. The larger change was architectural.

A Cleaner Information Architecture#

Instead of making every important thing compete on one long home page, the new portfolio is organized into clear destinations:

• Feed: Writing and technical insights
• About: experience, education, skills, and interests
• Research Publications
• Work: Projects & Case studies
• Résumé and Academic CV downloads

The homepage now acts as a live writing surface rather than a generic hero section. It pulls in recent technical articles from Hashnode, which makes the portfolio feel active and gives visitors a direct way to understand how I think.

This was intentional. A portfolio should not only say what you do; it should make your thinking visible.

From Static to Maintainable Content System#

One of the biggest changes was moving important portfolio content away from hardcoded front-end constants into a structured CMS model using Sanity.

The content system now manages:

• Projects
• Professional experience
• Education
• Skills and interests
• Research publications
• Social profiles and site settings

This matters because a portfolio should be easy to maintain over years, not only easy to launch once.

Instead of rewriting layouts whenever I add a project or publication, I can update structured content and let the presentation layer remain consistent. The application uses typed queries and adapters so CMS content is transformed into reliable UI data.

Building for performance from the start#

A polished portfolio should feel fast before a visitor has time to think about performance.

I focused on a modern application stack built around Next.js, React, TypeScript, Tailwind CSS, and server-rendered content. The architecture avoids unnecessary client-side work, serves content through revalidation, and keeps visual movement restrained enough that it supports the experience rather than competing with it.

After deployment, the results were encouraging.

The real-user desktop metrics were also strong:

These scores are not the finish line, but they validate an important principle: adding richer content, a CMS, analytics, and AI functionality does not have to produce a slow site.

Measuring Real Visitors#

Lighthouse and PageSpeed are useful because they provide a controlled test environment. But real-user monitoring tells a more complete story.

That is why I also integrated Vercel Analytics and Speed Insights. They help me understand how the deployed site behaves for actual visitors rather than only during a single synthetic audit.

The early desktop field data shows a Real Experience Score of 100. Mobile data is also healthy, but it highlights the next improvement area: Largest Contentful Paint.

At the time of measurement, mobile results showed:

This is exactly why field monitoring matters. A mobile Lighthouse score of 96 is excellent, but real-user data shows that mobile LCP still has room to improve.

The goal is not to hide that difference. The goal is to use it to guide the next iteration: identify the mobile LCP element, improve its loading path, and continue monitoring the effect with a larger sample size.

Search Engine Optimization as Product Feature#

SEO is often added near the end of a project. In this rebuild, it was part of the architecture.

The portfolio includes:

• Page-specific metadata
• Canonical URLs
• Open Graph metadata
• A dynamic social-image route
• robots.txt
• XML sitemap generation
• Bing site verification
• Semantic, server-rendered page content
• Structured data using JSON-LD

The structured data describes the site as more than a collection of pages. It communicates entities and relationships such as:

• The portfolio owner and professional identity
• Social profiles
• Writing and articles
• Software projects
• Research publications
• Education and professional experience
• Case studies and external links

This helps search engines interpret what the portfolio represents rather than just indexing isolated text fragments.

Designing for AI-assisted discovery#

Search is evolving. People increasingly ask tools like ChatGPT, Claude, Gemini, and Google AI-powered search experiences questions such as:

• Who is this person?
• What projects has this developer built?
• Find research on this topic.
• What should I read from this engineer?

A portfolio cannot force an AI system to use or cite it. These systems vary, their results can change, and an answer alone does not prove that a model has been trained on a website.

But a site can make itself easier to discover and understand.

For this portfolio, I added several foundations:

• Crawlable, server-rendered public pages
• Clear page hierarchy and descriptive content
• Structured metadata
• JSON-LD for key entities and content types
• Sitemap
• Explicit bot access rules in robots.ts
• An llms.txt file that identifies the canonical portfolio and its important pages

The claim is not “AI has learned my portfolio.”

It is:

The portfolio is designed to be accessible to crawlers and easier for search engines and AI-assisted search systems to interpret, cite, and navigate when they choose relevant public sources.

I will also be testing discoverability over time by checking:

• Google Search Console indexing and crawl status
• Search results for my name, role, projects, and research
• AI-assisted search responses that visibly cite the portfolio
• Referral traffic and crawler activity where available

If an AI-assisted search result cites the portfolio directly, that is useful evidence of source-level discoverability. If it only finds my LinkedIn, GitHub, or Hashnode profile, that still shows entity discoverability but it is not the same as a direct citation of the portfolio.

Adding an AI Portfolio Assistant#

One of the more experimental parts of the rebuild is an AI portfolio assistant.

The assistant is designed to help visitors explore my public work, research, technical writing, and professional background through natural questions. Rather than being a generic chatbot, it is grounded in portfolio-specific knowledge and can guide visitors toward relevant projects, articles, and downloadable materials.

The implementation also includes practical safeguards:

• Request validation
• Message-length and conversation-size limits
• Rate limiting
• Timeout handling
• Clear error states
• Source links and suggested follow-up questions
• A dedicated API route

The purpose is not to replace the portfolio’s navigation. It is to give visitors another way to discover the most relevant parts of the work.

Accessibility is still part of the roadmap#

The PageSpeed audit reached 86 for accessibility, which is a good result but not yet where I want it to be.

That is an important part of this case study: a performance score or successful deployment should not be treated as proof that a website is complete.

The next refinement pass will focus on the specific accessibility audit findings, including accessible names, semantic control labeling, contrast, and any remaining interaction details. Accessibility improvements are not cosmetic cleanup, they make the portfolio more usable and understandable for more people.

What I learned from the rebuild#

The main lesson is that a modern personal portfolio should be treated as a real product.

It should be:

• Visually intentional
• Fast on real devices
• Stable during loading
• Accessible
• Easy to update
• Searchable
• Structured for machines as well as humans
• Honest about remaining tradeoffs
• Measurable after deployment

The redesign gave me a cleaner visual identity, but the more valuable change is that the site now has a foundation for long-term growth.

It can host new writing, projects, research, case studies, and professional updates without needing another full rebuild every time my work evolves.

Muhammad Azlaan Zubair

Software Engineer and Researcher, writing about AI, developer tooling and automation.

WebsiteGitHubLinkedInInstagramThreadsXORICIDGoogle Scholar