I Didn’t Rebuild My Portfolio to Look Better. I Rebuilt It to Be Found
How I turned a visual showcase into a fast, CMS-powered professional platform for recruiters, search engines, and AI-assisted discovery
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
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.
| Metric | Result |
|---|---|
| PageSpeed desktop performance | 100 |
| PageSpeed mobile performance | 95 |
| Best practices | 100 |
| SEO | 100 |
| Accessibility | 86 |
| Vercel desktop Real Experience Score | 100 |
The real-user desktop metrics were also strong:
| Desktop field metric | Result |
|---|---|
| First Contentful Paint | 0.9s |
| Largest Contentful Paint | 2.9s |
| Interaction to Next Paint | 64ms |
| Cumulative Layout Shift | 0 |
| Time to First Byte | 0.46s |
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:
| Mobile field metric | Result |
|---|---|
| Real Experience Score | 85 |
| First Contentful Paint | 1.65s |
| Largest Contentful Paint | 3.51s |
| Cumulative Layout Shift | 0 |
| Time to First Byte | 0.69s |
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.txtXML sitemap generation
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
Explicit bot access rules in
robots.tsAn
llms.txtfile 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.
