DEV Community: Rishikumar Yadav

I Turned My Personal Portfolio Into an SEO Experiment

Rishikumar Yadav — Thu, 10 Sep 2026 04:41:36 +0000

What happens when you stop treating your portfolio as just a website and start treating it as a searchable representation of yourself?
I decided to find out.

Recently, I searched Google for:

“Rishikumar Yadav Portfolio”

The result was interesting.

My existing portfolio appeared on the first page, along with multiple pieces of my online presence:

Portfolio
DEV.to article documenting the portfolio rebuild
LinkedIn profile
Images associated with my online presence

This isn't a claim that I've "mastered SEO." It's simply a milestone in an ongoing personal SEO experiment.

Why I Started Doing This

I've always thought of a personal portfolio as more than a place to display projects. It should answer a simple question:

"Who is this person, and what has he built?"

When someone searches my name, I want them to be able to discover different parts of my work and understand that they're connected to the same person.

For me, SEO isn't only:

"How do I rank this website?"

It's also:

"How easily can someone find and understand my online presence?"

That led me to a slightly different approach to personal SEO.

My Goal: Make the Portfolio the Central Hub

I'm currently rebuilding my personal portfolio as a Laravel application. The long-term goal is for the portfolio to become the central hub of my online presence.

Something like this:

                         PORTFOLIO
                             │
           ┌─────────────────┼─────────────────┐
           │                 │                 │
           ↓                 ↓                 ↓
       LinkedIn            GitHub            DEV.to
           │                 │                 │
     Professional          Projects        Technical
        profile                              Writing
                             │
                             ↓
                       Other Platforms

Each platform has its own purpose.

Portfolio → the central connection
LinkedIn → professional identity
GitHub → code and projects
DEV.to → technical writing
Royal Road → creative writing

I don't want every platform to become a copy of the portfolio. I want each one to represent a different side of me while pointing toward a central source.

The SEO Work Behind the Result

The Google screenshot is the visible part. The more interesting part is the work happening behind the website. I've been working through the fundamentals of technical SEO rather than relying on a single trick or keyword.

1. Meta Tags

One of the first things I focused on was making sure every important page has meaningful metadata.

That includes things such as:

<title>Rishikumar Yadav | Web Designer & Frontend Developer</title>

<meta name="description" content="Rishikumar Yadav is a Web Designer and Frontend Developer specializing in modern websites, UI/UX, frontend development and SEO.">

Along with the standard viewport and other relevant metadata.
The idea is simple: "Every page should clearly communicate what it is about."

2. Canonical URLs

I also implemented canonical URLs.

For example:

<link rel="canonical" href="https://example.com/page"/>

Canonicalization helps communicate the preferred URL for a page when similar or duplicate URLs could potentially exist. It's a small implementation detail, but an important part of maintaining a clean URL structure.

3. Open Graph Metadata

SEO isn't limited to Google search results. A page should also look good when somebody shares it. That's why I worked with Open Graph metadata for social platforms.

For example:

<meta property="og:title" content="Rishikumar Yadav | Portfolio">
<meta property="og:description" content="Web Designer & Frontend Developer">
<meta property="og:image" content="https://example.com/images/og-image.jpg">
<meta property="og:url" content="https://example.com">
<meta property="og:type" content="website">

This controls how pages can be represented when shared across supported platforms.

4. Twitter/X Cards

I also added social card metadata for Twitter/X.
For example:

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Rishikumar Yadav | Portfolio">
<meta name="twitter:description" content="Web Designer & Frontend Developer">
<meta name="twitter:image" content="https://example.com/images/ogimage.jpg">

Again, the goal isn't simply ranking. It's making sure the content is represented properly wherever the URL appears.

5. JSON-LD / Schema.org

This is probably one of the more interesting parts of personal SEO. I worked with JSON-LD structured data to give search engines additional context about the website and the person behind it.
A simplified example of the concept:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Rishikumar Yadav",
  "url": "https://example.com",
  "sameAs": [
    "https://www.linkedin.com/...",
    "https://github.com/...",
    "https://dev.to/..."
  ]
}

The sameAs relationships are particularly interesting for a personal website.

Instead of thinking of these as completely separate identities:

Portfolio
LinkedIn
GitHub
DEV.to

The goal is to provide signals that they represent the same person.

Conceptually:

                 Rishikumar Yadav
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
      Portfolio       LinkedIn        DEV.to
          │              │              │
          └──────────────┼──────────────┘
                         ↓
                  Online Identity

Structured data doesn't magically make a website rank. It's about providing machine-readable context.

6. Google Search Console

I also use Google Search Console to understand how Google is discovering and indexing the site.

Some of the things I pay attention to include:

Search queries
Impressions
Clicks
Average position
Indexed pages
Indexing issues
Crawling
Search appearance

This is important because SEO shouldn't be based entirely on assumptions.

Instead of asking:

"I think Google likes this."

I can look at actual search data and see what is happening.

7. Google Analytics

Search visibility is only one part of the equation. I also use analytics to understand what happens after someone reaches the website.

Things such as:

Traffic sources
Landing pages
User navigation
Engagement
Popular pages
Traffic trends

A search impression is nice. A click is better. But understanding what happens after the click is where the data becomes much more useful.

8. PageSpeed Insights

I've also been using Google PageSpeed Insights to evaluate the technical performance of the website.

I pay attention to areas such as:

Performance
Accessibility
Best Practices
SEO
Core Web Vitals

SEO and performance aren't completely separate concerns. A website can have good content and metadata but still provide a poor experience if it is slow, difficult to use, or poorly optimized for mobile. So performance is something I want to consider during development, not after everything is finished.

9. XML Sitemap

I also work with an XML sitemap to expose the important URLs of the website to search engines.

For example:

/sitemap.xml

As the portfolio grows and more pages are added, having a properly maintained sitemap becomes increasingly useful for discoverability.

10. Robots.txt

The other basic piece is:

/robots.txt

It provides crawling directives for search engine bots. It's simple, but it's part of the basic technical foundation of a crawlable website.

The Interesting Part: Google Is Connecting the Pieces

This is what I found most satisfying about the result. The search wasn't showing only one website. It was showing multiple properties associated with my name.

Rishi Kumar Yadav
        │
        ├── Portfolio
        │
        ├── DEV.to
        │
        ├── LinkedIn
        │
        └── Images

That's the direction I want to continue moving toward.

Not just:

"My website ranks."

But:

"My online presence is understandable."

Personal SEO Is an Ecosystem

I think it's easy to approach SEO as a collection of isolated tasks.

Add keywords.
Add metadata.
Build backlinks.
Submit sitemap.
Wait for rankings.

But personal SEO feels different to me.

It's more like building an ecosystem.


                    PORTFOLIO
                   /    |    \
                  /     |     \
                 ↓      ↓      ↓
            LinkedIn  GitHub  DEV.to
                │       │       │
                ↓       ↓       ↓
           Professional Code   Writing
                │       │       │
                └───────┼───────┘
                        ↓
                  Online Identity

Each platform contributes something different.

The portfolio provides the central source.
LinkedIn provides professional context.
GitHub provides technical evidence.
DEV.to provides written expertise.
Other platforms provide additional context about the person behind the work.

The Bigger Lesson

I don't consider appearing on the first page for my own name + portfolio a massive SEO achievement. It's a small milestone. But it's a useful one. Because it shows that the different pieces I've been building are beginning to appear together in search.

And that's exactly what I wanted. I don't want my online presence to be a collection of disconnected profiles. I want someone searching for Rishikumar Yadav to be able to discover:

Who I am.
What I build.
What I write.
What I've worked on.
What I'm interested in.

My portfolio will eventually become the central hub for all of that. For now, I'm documenting the process. The portfolio isn't finished. But Google is already starting to show the pieces. And that's a pretty satisfying place to be.

Have you searched your own name?
If you're a developer, designer, writer, or creator, try searching your own name and see what Google associates with you.

You might be surprised by what you find.

Rishikumar Yadav

Turning My Personal Portfolio Into a Laravel Application

Rishikumar Yadav — Mon, 07 Sep 2026 09:47:10 +0000

Turning My Personal Portfolio Into a Laravel Application

I started this project with a fairly simple goal:

Build my personal portfolio.

But instead of stopping at a collection of frontend pages, I decided to turn it into a proper Laravel application.

The idea is simple: the public website should showcase my work, while a private backend should eventually allow me to manage the content without constantly editing Blade files.

The foundation

The project is being built with Laravel 13. I already had the frontend design, so I didn't want to redesign everything just because I was moving to Laravel.
Instead, I converted the existing HTML structure into Blade.

The frontend now uses reusable layouts and partials for things such as:

Header
Footer
Offcanvas navigation
Head/SEO
JavaScript assets

This keeps the page-specific Blade files focused on their actual content.

The Contact System

The first complete backend feature I built was the contact system. The public contact form now submits to Laravel instead of using a static HTML action.

The flow is: Visitor → Contact Form → Laravel → Database → Admin

Messages are stored in the database with information such as:

Name
Email
Subject
Message
Read/unread status
Read timestamp

Building Admin

I also started building the private administration panel.
The public website and the administration panel are intentionally separated.

The current Admin system includes:

Private login
Session-based authentication
Account active/inactive checking
Login rate limiting
Protected routes
Security headers
No-index directives
Contact message management
Read/unread status
Pagination
Message deletion

The login system also limits repeated failed attempts instead of allowing unlimited password attempts.

Why I'm building it this way

The goal isn't just to have an admin dashboard because it looks cool. Eventually, I want to manage the portfolio itself from there.

Projects
Skills
Experience
Achievements
Services
Journal
Social links
SEO
Media
Settings

The public website should eventually consume that data rather than having everything hard-coded into the frontend.

One important distinction

I'm also keeping my writing separate from the Journal. Writing will belong to my achievements and extra-curricular activities. Journal will be its own content type. That distinction matters because they serve different purposes.

What's next?

The next major step is building the Journal system. I already have the frontend archive and article-detail designs. The plan is to build the database structure around those designs and eventually add a rich-text editor to admin so I can write articles more like using a document editor instead of manually writing HTML.

For now, the foundation is in place. And that's probably the most important part. A portfolio is easy to make.

Building one that can actually evolve with you is more interesting.

I Built My Own Budget Tracker - Because I Didn't Want to Pay a Monthly Subscription

Rishikumar Yadav — Sat, 05 Sep 2026 06:14:00 +0000

## Why I Built My Own Personal Budget Tracker

For a long time, I wanted a simple way to keep track of my personal finances. Not something complicated. Not something that required learning a financial system. And definitely not something that asked me to pay a monthly subscription just to keep track of my own money. So I decided to build one myself. That project eventually became a Personal Budget Tracker & Finance Analytics Tool.

The Problem

There are plenty of budgeting and personal finance applications available today. Many of them are actually good.

But I kept running into the same problem:

Why should I have to pay every month to track my own budget?
For someone who simply wants to record income, expenses, savings, accounts, and transactions, a subscription can feel unnecessary.

I wanted something that I could:

Build for myself
Customize whenever I wanted
Understand completely
Host privately
Extend with features I actually needed
Use without a recurring subscription

And since I'm a web designer and developer, the obvious answer was:
Build it myself.

From a Simple Idea to an Actual Application

The original idea was extremely simple:

"I just need somewhere to record my expenses."

But once I started designing it, I realized that simply recording expenses wasn't enough. Money doesn't exist in isolation.

You have different accounts.
You receive income.
You spend money.
You transfer money between accounts.
You save.
You may have cash, bank accounts, wallets, investments, or other financial sources.

So instead of building just an expense tracker, I started thinking about the bigger picture.

The goal became:

Build a complete personal finance tracker rather than just an expense list.

What I Built

The application gradually evolved into a personal finance dashboard with multiple parts working together.

a] Dashboard

The dashboard provides an overview of the current financial situation.
It focuses on things such as:

- Total Income
- Total Expenses
- Savings
- Account Balances
- Financial Activity
- Overall Financial Position

The idea is that I shouldn't have to open multiple pages just to understand what's happening with my money.

b] Accounts

Accounts are one of the core parts of the application. Instead of treating all money as one balance, the application keeps track of individual accounts.

For example:

Bank Account
Cash
Digital Wallet
Savings Account

Each account can have its own transactions and balance.
This also makes it possible to understand where the money actually is, rather than only knowing how much money exists in total.

c] Transactions

Transactions are the heart of the tracker. Every financial movement needs to be recorded correctly.
A transaction can represent things such as:

Income
Expense
Transfer

This sounds simple, but transaction logic becomes surprisingly important once multiple accounts are involved.

For example, if I transfer ₹5,000 from Bank A to Bank B:

Bank A
-₹5,000

Bank B
+₹5,000

My total money hasn't changed. Only its location changed. That distinction is important when calculating balances, savings, and net worth.

d] Bank-to-Bank Transfers

One of the features I specifically wanted was proper account-to-account transfers. A transfer should not be treated as income and expense. Otherwise, transferring money between my own accounts would incorrectly make it look like I earned and spent additional money. So the application treats transfers as their own financial operation.

For example, transferring ₹5,000 from Bank A to Bank B:

Bank A
-₹5,000

Bank B
+₹5,000

Otherwise, transferring money between my own accounts would incorrectly make it look like I earned and spent additional money.
So the application treats transfers as their own financial operation.

Conceptually:

Account A
    ↓
Transfer
    ↓
Account B

The overall net worth remains unchanged. Only the account balances change.

e] Balance Logic

One of the areas where the project became more interesting was handling account balances correctly.

I didn't want balances to be manually maintained.

Instead, the current balance is calculated based on the account's opening balance and all the transactions associated with it.

Conceptually:

Opening Balance
+ Income
- Expenses
- Transfers Out
+ Transfers In
= Current Balance

This makes the transaction history the source of truth. If something looks wrong, I can inspect the transactions instead of wondering why a manually entered balance doesn't match reality.

For example:

Opening Balance      ₹20,000
Income              +₹10,000
Expenses             -₹4,000
Transfers Out        -₹3,000
Transfers In         +₹2,000
--------------------------------
Current Balance      ₹25,000

That helps keep account balances consistent as the number of transactions grows.

f] Net Worth

Another feature that naturally came out of the project was net worth.
Instead of only asking:

"How much money do I have in this account?"

I wanted to be able to see my overall financial position.

The basic idea is:

Total Assets
- Total Liabilities
= Net Worth

For example:

Bank Account        ₹50,000
Savings Account     ₹30,000
Cash                ₹10,000
----------------------------
Total Assets        ₹90,000

Credit Card Due     ₹15,000
----------------------------
Net Worth           ₹75,000

This gives a much clearer picture of the overall financial position rather than looking at individual account balances separately. It also means that moving money between my own accounts doesn't artificially increase my net worth.

Tech Stack

The project is built using a simple and familiar web technology stack.

I didn't want to overcomplicate the architecture. The goal was to use technologies I already understood and could maintain myself.

The main stack includes:

HTML
CSS
JavaScript
PHP
MySQL

The frontend handles the interface and interaction.
PHP handles the server-side logic.
MySQL handles the financial data.
The architecture isn't designed to be unnecessarily complicated.
For a personal finance application, I would rather have a system that I understand completely than add layers of technology simply because they're popular.

Design Philosophy

While building the tracker, I didn't want it to feel like a traditional accounting application.
Personal finance can already feel complicated, so I wanted the interface to make things easier to understand rather than adding more complexity.

The main goal was:

Simple
  ↓
Clear
  ↓
Useful
  ↓
Reliable

The idea was:

Useful Feature
      ↓
Solves a Real Problem
      ↓
Keep It

rather than:

Feature
Feature
Feature
Feature
Feature
      ↓
More Complexity

For me, good design isn't about making an application look impressive. It's about making the application easy to understand, comfortable to use, and reliable enough to trust.

The project isn't just a concept or a demo.It evolved into a private tracker that is being used by a small group of people close to us.

That changed how I approached development. When you're building something only for a portfolio, it's easy to say: "This should work."

When real people use it, you start asking different questions:
What happens if someone enters incorrect data?
What happens when an account becomes inactive?
What happens when money moves between accounts?
What happens when there are hundreds of transactions?
Can users understand what the dashboard is showing?
Can financial data be recovered?
What happens when something doesn't match?

Real usage exposes problems that aren't always visible during development. And that's probably one of the most valuable parts of building this project.

What I Learned

Simple applications aren't necessarily simple to build
Data correctness matters more than visual design
Real users are better testers than assumptions

Instead of trying to predict every possible requirement, I'm letting real usage help determine what should be improved next.

What's Next?

The project is now moving toward Version 1.1.
Rather than adding dozens of random features, the next version is focused on a few practical improvements.

Planned for Version 1.1
ITR Filing Details
Monthly Financial Snapshots
Small Financial Insights

The idea is to build these based on actual usage and feedback rather than simply adding features because they sound interesting.

Why I Didn't Just Use Excel ?
This is probably the obvious question. Yes, I could have built a spreadsheet. And honestly, spreadsheets are incredibly powerful.

But building the application myself gave me something a spreadsheet couldn't:

A system designed specifically around the way I wanted to manage my finances.
I can decide how accounts work.
I can decide how transactions behave.
I can design the dashboard.
I can add features when I need them.
And most importantly: I understand what's happening behind the interface.

This Started as a Personal Project, I didn't start this project thinking:

"I'm going to build a finance product."

I started with:

"I want to track my budget without paying a monthly subscription."

That's it.

The application grew from that simple requirement. And I think that's one of the best ways to build software.

Start with a real problem.
Solve it.
Use the solution.
Find the problems with your solution.
Improve it.
Repeat.

Final Thoughts

Building this Budget Tracker has been less about creating another finance application and more about learning how to build software that people can actually rely on.

It combines several things I enjoy:

Web Design
Frontend Development
Backend Development
Database Design
UX
Data Visualization
Problem Solving

And there's still a lot left to improve. For now, the goal isn't to build the biggest personal finance application. It's to build a simple, reliable and useful one.

One that solves the problem that started everything: I just wanted to keep track of my money without paying a monthly subscription.

And apparently, the easiest way to get that was to build the thing myself.

Thanks for Reading

If you're also building a personal project, I'd love to hear about it. Sometimes the smallest problems make the most interesting projects.

Rishikumar Yadav

What is GEO (Generative Engine Optimization) — and Why You Should Care as a Web Designer & SEO Specialist

Rishikumar Yadav — Fri, 10 Oct 2025 10:39:28 +0000

In recent years, the way users search for information online has shifted dramatically. Instead of typing a keyword into Google and scrolling through a list of results, more and more people are using AI-powered tools like ChatGPT, Gemini, Perplexity, Bard, and others. These tools often give direct, conversational, synthesized answers rather than just a list of links.

To stay visible in this changing landscape, a new optimization strategy has emerged: Generative Engine Optimization (GEO). If you work in web design, frontend development, server management, or SEO — GEO is something you must understand and start integrating into your work.

What Exactly Is GEO?
GEO stands for Generative Engine Optimization.
It refers to optimizing your content (and technical setup) so that AI tools are more likely to pick your site’s content as part of their answers. That means better structure, clarity, credibility, and context — not just keywords.[2]
Unlike traditional SEO, where the goal is to rank high in search engine result pages (SERPs), GEO is about being cited or used in AI-generated responses. Think of it as optimizing for a world where users may never click through to a link because the AI tool already gave them your answer.[1]

Key Differences: GEO vs SEO

Main Goal
Traditional SEO focuses on ranking well in search engine results pages (SERPs) like Google or Bing by using keywords, backlinks, and other ranking factors. In contrast, GEO (Generative Engine Optimization) aims to have your content included or cited in AI-powered answers, summaries, or overviews produced by generative search engines and AI assistants.
Content Style
SEO content is typically keyword-rich, often optimized around search volumes and may use repetition for ranking purposes. GEO content, on the other hand, emphasizes clarity, structure, depth, semantic meaning, readability, and authority — making it more useful for AI systems to reference and summarize.
Structure
With SEO, structure revolves around meta tags, headings, internal linking, page speed, and backlinks. GEO builds on these basics but adds structured data/schema, FAQ or Q&A sections, clarity, use of lists and summaries, and citing credible sources — elements that help AI engines understand and extract information more effectively.
Measurement
SEO success is measured through organic traffic, rankings, click-through rate (CTR), and backlinks. GEO success is measured differently: it’s about visibility in AI-generated results, citation frequency, and how often your content is used within AI-generated answers.

Why GEO Matters — Especially for You
If your work involves frontend development, SEO, server management, content design, GEO gives you a chance to lead, not get left behind.

Here’s why:

First-mover advantage: Many sites are still optimized only for traditional SEO. Implement GEO principles early and you’ll be ahead of competitors in being surfaced by AI tools.

User behaviour is changing: More people are asking questions in natural language, expecting instant answers. The role of conversational search / AI assistants is growing. If your content is not AI-friendly, you may be invisible to a large chunk of your audience.

Design & performance gains double up: Good structure, fast loading, clean markup, good accessibility — all help both for SEO and GEO. So your skills in frontend & server optimization matter more than ever.
Brand authority & trust become even more critical: AI models often prefer citing sources that appear authoritative, up-to-date, and useful. Ensuring that your content shows experience, expertise, authority, and trustworthiness (E-E-A-T) is essential. [3]

How to Optimize for GEO: Practical Steps
Here are actionable things you can do, especially with your web design / frontend / server + SEO combo:

Organize content clearly. Use headings (H2, H3), bullet lists, FAQs. Summaries at top or bottom. Make content “scannable”.

Rich media & context. Include images, diagrams, maybe even short videos. Sometimes AIs include images or visuals.

Citations & references. Link out to credible sources; quote stats or research. This signals credibility.

Technical health. Good page speed, mobile responsiveness, SSL, structured data (schema.org) are even more important. If AI can’t crawl or understand your content well, it won’t use it.

Semantic/Conversational keyword research. Think about how people ask questions naturally. Use long-tail, question forms (“how to”, “why is”, etc.).

Monitor and iterate. Use tools / analytics to see what content gets cited / utilized by AI engines, then refine. You might measure brand mentions in AI, or test prompts and see which content shows up.

Challenges & What to Watch Out For

Metrics are still evolving. Geo visibility isn’t as well-defined as “rank on page 1” yet.
Dependence on AI platforms’ black-box behaviours. Models update often, criteria may change.
Potential for over-optimization; content that reads too much like it’s “made for AI” can lose human appeal. Balance is key.
Risk of bigger brands dominating citations since authority, existing backlinks, and trust give them an advantage. Smaller players will need to lean into niche authority, unique content, expertise.
Conclusion
Generative Engine Optimization is not a replacement for SEO — it’s an evolution. As AI-powered search and answer tools become more mainstream, GEO will become increasingly important.

If you can adapt your workflow (frontend design, content structure, performance, credibility) to be friendly both to humans and AI systems, you’ll not only preserve visibility — you’ll expand it into channels many competitors are still ignoring.

References
HubSpot (2024). The Marketer’s Guide to Generative Engine Optimization (GEO).
Mangools (2024). Generative Engine Optimization: The Future of SEO in the Age of AI.
AIOSEO (2024). Generative Engine Optimization (GEO): How to Optimize for AI Search Engines.