# 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. ![Full-page screenshot of the new portfolio about-page.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/ee933bac-1a14-4e62-9554-74dce9358e8e.png align="center") * * * ## 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**](https://mdazlaanzubair.com/)**:** Writing and technical insights * [**About**](https://mdazlaanzubair.com/about)**:** experience, education, skills, and interests * [**Research Publications**](https://mdazlaanzubair.com/research) * [**Work**](https://mdazlaanzubair.com/projects)**:** Projects & Case studies * [**Résumé**](https://mdazlaanzubair.com/about) and [**Academic CV**](https://mdazlaanzubair.com/about) downloads The homepage now acts as a live writing surface rather than a generic hero section. It pulls in recent technical articles from [**Hashnode**](https://blog.mdazlaanzubair.com/), which makes the portfolio feel active and gives visitors a direct way to understand how I think. ![screenshot of the writing homepage and article list.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/9ad31876-276f-4d3e-827f-fe34455ae815.png align="center") 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](https://dev.to/shubhampatilsd/sanityio-a-really-good-cms-42h9) model using [**Sanity**](https://www.sanity.io/). 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. ![screenshot of Sanity Studio showing the structured content model or a project entry.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/f1a5edbf-6fe7-4cbc-9f2a-a68c826179b3.png align="center") * * * ## 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](https://nextjs.org/docs/app/guides/ai-agents), [React](https://react.dev/learn), [TypeScript](https://www.typescriptlang.org/docs/handbook/intro.html), [Tailwind CSS](https://tailwindcss.com/plus), and [server-rendered](https://nextjs.org/docs/pages/building-your-application/rendering/server-side-rendering) 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 | ![Google PageSpeed desktop screenshot showing 100 performance, 100 best practices, and 100 SEO.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/0a594105-2a7d-4584-883e-95543237d16c.png align="center") * * * ![Vercel desktop Speed Insights screenshot showing the 100 Real Experience Score.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/731d9cb0-231b-441e-ade1-284b613a2bde.png align="center") 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](https://developer.chrome.com/docs/lighthouse) and [PageSpeed](https://pagespeed.web.dev/analysis/https-mdazlaanzubair-com/onuvxw90gr?form_factor=mobile) 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](https://vercel.com/docs/analytics) and [Speed Insights](https://vercel.com/docs/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.txt` * XML sitemap generation * [Bing site verification](https://www.bing.com/webmasters/help/add-and-verify-site-12184f8b) * Semantic, server-rendered page content * Structured data using [JSON-LD](https://nextjs.org/docs/app/guides/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. ![diagram showing: Portfolio content → Semantic HTML + metadata + JSON-LD + sitemap → Search engines and AI-assisted search.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/8d98f9e3-0e5a-4ba4-8a90-77da8af9098e.png align="center") * * * ## 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**](https://github.com/mdazlaanzubair/the-chronicles-of-UI-UX/blob/main/app/sitemap.ts) * **Explicit bot access** rules in [`robots.ts`](https://github.com/mdazlaanzubair/the-chronicles-of-UI-UX/blob/main/app/robots.ts) * An [`llms.txt`](https://github.com/mdazlaanzubair/the-chronicles-of-UI-UX/blob/main/public/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. ![screenshot of robots.txt, sitemap.xml, or llms.txt in the deployed portfolio.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/cfa256c0-24ec-44dd-a4a5-6c123b945a13.png align="center") * * * ![screenshot of robots.txt, sitemap.xml, or llms.txt in the deployed portfolio.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/ee035545-d639-41ac-9a8c-63f4ddd39f06.png align="center") I will also be testing discoverability over time by checking: * [Google Search Console](https://search.google.com/search-console/about) 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](https://mdazlaanzubair.com/) directly, that is useful evidence of source-level discoverability. If it only finds my [LinkedIn](https://www.linkedin.com/in/mdazlaanzubair/), [GitHub](https://github.com/mdazlaanzubair), or [Hashnode](https://hashnode.com/@mdazlaanzubair) profile, that still shows entity discoverability but it is not the same as a direct citation of the portfolio. %[https://youtu.be/5Cog_F0NfSY] * * * ## 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 ![screenshot of the “Ask Leo” assistant open, ideally showing a response with sources.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/47550cf1-2e7b-4319-b1c4-e8c8219566e0.png align="center") 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.