I Traced 18 Years of a Website. Here’s What Happened to Its SEO, UX and URLs

From its earliest archived pages to its current incarnation, I followed the site’s URLs, search visibility, redesigns, broken assets and digital experience to see what survived, what disappeared, and what went wrong.

This website survived 18 years of redesigns. Its SEO didn’t always survive with it.

About this investigation

• Website investigated: KLE Society’s College of Business Administration, Hubballi (KLE CBA)
• Investigated by: Vikas Solanke | Website.gy
• Industry: Higher Education, Business Administration & Management Education
• Investigation period: 2008–2026 Current website reviewed: August 2026
• Nature of investigation: Historical website analysis, website evolution, URL architecture and migrations, redirect analysis, search visibility and SEO performance, technical SEO, crawlability and indexability, website content, broken and outdated assets, information architecture, forms and lead capture, chatbot functionality, user experience, content freshness, and digital infrastructure

A college website is easy to underestimate.

At first glance, it seems straightforward.

Put the college name at the top. Add the courses. Show some photographs. Publish admissions information. Add contact details. Make it mobile-friendly. Launch it.

Done.

Except it isn’t.

Not when the website belongs to an established educational institution.

And definitely not when that website has been online for almost two decades.

That was what caught my attention when I started looking at the website of KLE Society’s College of Business Administration, Hubballi, commonly known as KLE CBA > klecbahubli.org

I wasn’t interested in doing the usual “10 things wrong with your website” exercise.

I wanted to go much deeper.

I wanted to know:

What happened to this website over the last 18 years?

So I went backwards.

I looked at historical versions of the website, its URL structures, its search visibility over time, major redesigns, redirects, content, forms, user journeys and some of the smaller details that are very easy to miss when you’re only looking at the current homepage.

I spent a significant amount of time on it to understand things.

And honestly, the deeper I went, the more interesting the story became.

Let’s go back to 2008

The earliest version of the KLE CBA website I could identify dates back to July 2008.

And before we judge that website by today’s standards, let’s be fair.

2008 was a completely different internet.

Flash was everywhere. Websites had animated buttons, gradients, splash screens and enough visual effects to make today’s designers break into a cold sweat.

The important thing here isn’t whether the 2008 website looks old.

Of course it does.

What matters is the technology behind it.

The website relied on Flash or similar technology. At the time, this created significant limitations around how easily search engines could crawl, index and understand the site’s content.

I actually like looking at old websites for this reason.

Personally for me, its crazy nostalgia, since I ve been active and I’ ve experienced this phase of the internet.

Not only do they show you how much the web has changed, but they also remind you of something important:

A website can look outdated without necessarily being badly built for its time.

And the reverse is equally true.

A website can look spectacular and still be technically poor.

So I wasn’t interested in judging the 2008 design.

I was interested in what happened when the website evolved.

2017: The first major technical improvement

Around 2017, KLE CBA redesigned the website.

And this time, there was a significant technical improvement.

The Flash based elements were removed and the website moved towards HTML based rendering, making the content much easier for search engines to crawl, index and understand.

That change appears to have made a substantial difference.

The historical data shows the website moving from approximately 5 ranking keywords to nearly 100.

That’s roughly a 20x increase.

This is one of my favourite lessons from the entire audit.

Sometimes good SEO isn’t about adding more SEO. Sometimes it’s simply about removing the things that prevent search engines from understanding the website.

But there was another change during the 2017 redesign.

And this one is much more interesting.

The URLs changed

The original website of 2008 had relatively simple URLs:

Section	Earlier URL
About	/about.html
Academics	/academics.html
Placements	/placements.html
Contact	/contact.html

The 2017 version changed that architecture.

The homepage moved into:

/klecba/home

The About page became:

/klecba/about_us

The Academics page disappeared.

The Placements page disappeared.

The Gallery moved to:

/klecba/gallery

The Contact page became:

/klecba/contact_us

The historical audit also found broken image links within the Gallery.

Now, there’s nothing inherently wrong with using a folder such as /klecba/ for the gallery or other pages, if there is a strong technical reasoning behind the change.

The problem is not the existence of that folder.

The problem is changing established URLs without treating the migration as an important technical event.

Because URLs are not just addresses sitting inside a browser.

Over time, they can accumulate:

• Search engine visibility
• Backlinks
• External references
• Bookmarks
• Traffic
• Historical signals
• User familiarity

Once a page has existed for years, changing its URL is not quite the same thing as renaming a file on your computer.

The 302 redirect that made me stop

The 2017 implementation also introduced another interesting change.

The primary domain was redirecting to the /klecba location, and the historical audit recorded that redirect as a 302 temporary redirect rather than a permanent 301 redirect.

This is exactly the sort of detail that a normal visitor would never notice.

They type the domain.

The website opens.

Everything seems fine.

But from a technical perspective, a site migration should be much more deliberate.

Google’s current documentation recommends mapping old URLs to their new equivalents and using appropriate permanent redirects when pages have permanently moved. That allows search engines to understand the relationship between the old and new locations. (developers.google.com)

And this is the question I keep coming back to when looking at old websites:

What happens to everything the old website has already earned when we build the new one?

That’s the question that matters.

The strange part: the website still grew

Here’s where things get interesting.

Despite the URL architecture changes, the website’s search visibility continued to improve.

The site went from roughly 5 ranking keywords to almost 100 by July 2018.

That’s important because it prevents us from making a lazy conclusion.

We cannot simply say:

“The 2017 URL structure was bad, therefore the website immediately collapsed.”

It didn’t.

The site actually grew.

The move away from Flash and the resulting improvement in crawlability and indexability appears to have helped the site substantially.

And then came July 2018.

Then the graph falls off a cliff

By July 2018, the website had reached close to 100 ranking keywords in the historical SEMrush data.

Then, within approximately four months, the number had fallen to 1 keyword by November 2018.

That’s approximately a 99% decline in the number of ranking keywords recorded in the dataset.

This is the kind of graph that makes anyone who has spent years working on websites stare at the screen for a few seconds.

Not because ranking drops are unusual.

They aren’t.

But a drop of this magnitude deserves investigation.

So I kept digging.

Another redesign. Another URL structure.

The historical evidence points to another website redesign around June or July 2018.

This time, the website was developed by an external web design company. The redesigned website included a link from the KLE CBA website to the developer’s own website across the site’s pages.

Now, let’s pause here.

There is nothing inherently wrong with a developer credit.

If someone builds a website, there’s nothing strange about saying:

Website by XYZ

That’s normal.

The interesting part is how those links are implemented and distributed.

Google’s current spam policies specifically identify widely distributed links in footers or templates as an example of link spam when they are created primarily to manipulate search rankings.

So this is an area worth documenting.

But I’m deliberately not going to say:

“This footer link caused KLE CBA to disappear from Google.”

We don’t have enough evidence to make that claim.

What we can establish is that the period included several major changes:

• Another website redesign
• Another URL architecture
• Existing URLs being replaced
• A sitewide external developer link
• A dramatic decline in search visibility shortly afterwards

That’s enough to make the relationship worth investigating.

And that’s how a proper audit should work.

Evidence first. Conclusions second.

Let’s talk about the URL migration

The 2018 version moved important pages into a new structure such as:

/home/about

The earlier URL structures were no longer being carried forward consistently through redirects, according to the audit.

This is where I like using a very simple analogy.

Imagine you open a vada pav centre on 6th Avenue (location 1)

You run it for years.

People know the location.

Customers tell their friends.

Other websites mention the address.

Then one morning you move the entire shop to 15th Avenue (location 2)

But you don’t put up a sign.

You don’t tell customers.

You don’t tell suppliers.

You don’t leave a “We’ve moved” message at the old location.

You simply disappear from Station Road.

What happens?

People keep going to the old place.

They find nothing.

And eventually, they stop looking.

A proper website migration should work differently.

You tell the old address where the new address is.

That’s essentially what redirects are doing on the web.

And when established URLs are changed, Google itself recommends a structured migration process that includes URL mapping and appropriate redirects. (developers.google.com)

That part of a redesign is not glamorous.

Nobody puts it in the homepage mockup.

Nobody gets excited about it in a presentation.

But it can be one of the most important parts of the entire project.

The site eventually recovered

And this is where I want to be fair.

The website did not remain at the bottom forever.

It recovered.

Quite significantly.

After the late-2018 collapse, the domain gradually rebuilt its search visibility.

By February 2022, the website was appearing for approximately 215 ranking keywords in the historical SEMrush data.

Those are genuinely good numbers considering the site’s earlier history.

And I don’t want to take credit away from whoever was responsible for the website during that period.

The report itself notes that increased internet activity during the COVID period may also have contributed to improved performance.

Search visibility is complicated.

It is influenced by many things:

• Content
• Competition
• Search demand
• Technical changes
• External links
• Search algorithms
• User behaviour
• Broader changes in how people search

So yes, the recovery deserves to be acknowledged.

But then something else happened.

From 215 keywords to around 80

After reaching approximately 218 ranking keywords, the website subsequently declined to around 73.

That’s close to a 65% reduction in the number of ranking keywords recorded in the dataset.

And once again, I had the same question:

What really changed?

This time, the investigation led me to another major change in the website’s structure.

The 25th Anniversary Homepage

The college celebrated an important milestone.

25 years.

That’s absolutely worth celebrating.

There is nothing wrong with putting an anniversary message on a college website.

The problem was not the anniversary.

The problem was how the anniversary experience was implemented on the website.

The primary homepage was effectively taken over by the anniversary message.

The visitor then had to click:

CLICK HERE TO PROCEED

to enter the rest of the website.

Again, I want to separate the idea from the implementation.

The anniversary message was perfectly legitimate.

The implementation is what deserves scrutiny.

The visitor started at:

klecbahubli.org

and clicking the button took them into:

klecbahubli.org/home/main

That means the primary website journey had once again been changed.

And this is exactly where seemingly innocent website decisions can become technically important.

The URL history is now telling a story

Put the major versions together and you get this:

Year	Example URL structure
2008	/about.html
2017	/klecba/about_us
2018	/home/about
2026	/About/KLE+Society

This is probably my favourite visual in the entire audit.

Because suddenly, you don’t need me to explain the problem.

You can see it.

The website didn’t simply get redesigned over the years.

Its underlying address system kept changing.

And that is exactly why URL architecture needs to be treated as part of the website’s long-term infrastructure.

And then we arrive at the 2026 website

Now let’s come back to today.

The current website is obviously far more modern than the 2008 version.

But after spending all this time looking backwards, I started noticing things on the current website that are very easy to miss if you only spend five minutes looking at the homepage.

Let’s go through them.

The Gmail address

The current website displays a Gmail address as an institutional contact address.

There is absolutely nothing wrong with Gmail.

Gmail is excellent.

But for an established educational institution operating on its own domain, a domain-based email address communicates something different.

Compare:

klebbahubballi@gmail.com

with:

admissions@klecbahubli.org

The second immediately feels like part of an institutional communication system.

It also creates room for proper departmental addresses such as:

• admissions@
• principal@
• placements@
• alumni@
• office@
• accounts@

This isn’t about looking fancy.

It’s about institutional identity, departmental delegation of processes, and control.

The YouTube link is outdated

The website currently points visitors towards:

@klebbahublihubli2743

while the YouTube channel itself uses:

@KLECBA

The audit identified this mismatch in the current website.

It’s a tiny thing.

But these tiny things add up.

A website is constantly communicating one message:

“We take care of our digital presence.”

Broken or outdated links quietly communicate the opposite.

The Blog is broken

Now let’s click the Blog link.

The website has a Blog item in the navigation.

Perfectly reasonable.

A college should be publishing updates, events, announcements, student stories, achievements and other institutional content.

Except the current Blog URL:

/blog/

is broken.

The audit captured an:

Error establishing a database connection

That’s not an SEO theory.

That’s not a matter of opinion.

That’s simply a broken section of the website.

And because the link is sitting inside the main navigation, the website is actively inviting visitors to click it.

The Notices section has gone quiet

The homepage also displays a Notices section.

Again, good idea.

Students need notices.

Parents need notices.

Applicants need notices.

But during the audit, the latest visible notice was dated May 2024.

Now imagine you’re a prospective student.

You land on the official website of a college.

You see a section labelled:

Notices

You expect recent institutional communication.

Instead, you see information that is more than two years old.

What does your brain naturally conclude?

Probably not:

“What an impressive archival system.”

More likely:

“Is this website still being maintained?”

That’s the problem with stale content.

It doesn’t merely provide old information.

It can change how the visitor perceives the entire institution.

Then I tested the chat

The website prominently tells visitors that the team is:

“online and ready to help”

Excellent.

So I tried it.

The website tells visitors that the team is online and ready to help.

Then I sent a message.

And waited.

And tried again.

And again.

The audit found the same unavailable response repeatedly over approximately five days of testing.

Here’s the problem.

If the website says:

We’re online.

I expect someone to be online.

If nobody is available, that’s completely fine.

Just tell me that.

A website should not make a promise that its actual workflow cannot keep.

Then I tested something much more important

Admissions.

There is a floating enquiry form asking visitors to submit their details so that an admission counsellor can contact them.

So I filled it in.

And I deliberately entered nonsense.

The form accepted it.

Now, let me explain something about web forms.

Back in 2005 or 2006, when I started coding my own forms, I once sent one of my forms to a friend working at Google’s Mountain View office in the US.

His response was wonderfully brutal:

“Nice work, but it’s a dumb form.”

That sentence stayed with me.

Because a form can look perfectly fine and still be dumb.

What makes a form dumb?

A form becomes dumb when it simply collects whatever somebody types and throws it somewhere without understanding what the information actually means.

In this case, the audit found:

• No meaningful form validation
• Acceptance of nonsensical data
• No reference number
• No visible tracking mechanism for follow-up

And that raises a much bigger question:

When a prospective student fills this form at 11:43 PM from another city, where does that enquiry actually go?

That’s the question I would want answered.

Because an admissions form isn’t a decorative component.

It’s a lead-management system.

Or at least, it should be.

The grievance form has the same problem

The Students’ Grievance Redressal Form deserves even more attention.

A grievance is not an ordinary contact enquiry.

A student submitting a grievance should ideally receive a reference number and have some mechanism to understand whether the matter is pending, being reviewed or resolved.

The audit found no visible tracking mechanism of that kind.

A proper workflow should look something like:

Submit → Reference Number → Assigned → Under Review → Action Taken → Resolved

The website should not simply stop at:

Submit → Thank you

For something as important as a student grievance, that’s not enough.

There is much more underneath

And this is where I have to stop myself.

Because the audit uncovered many additional areas involving:

• Performance
• Security
• Information architecture
• Content management
• Forms
• Notices
• Gallery management
• Lead tracking
• User experience
• Technical architecture

I could easily turn this into a 50-page technical report.

But that’s not the purpose of this article.

The purpose is to demonstrate something much more important.

A website redesign is not just a design project

This is where I think many organisations get website projects wrong.

They think:

“Our website is old. Let’s build a new one.”

Fair enough.

But that’s only the first sentence.

The next questions should be:

What already exists?

Which URLs are indexed?

Which pages have backlinks?

Which pages receive traffic?

Which content has accumulated value?

Which pages do students actually use?

Which pages do prospective students need?

What happens to the existing forms?

What happens to notices?

What happens to the blog?

What happens to the sitemap?

What happens to the old URLs?

What happens to the search visibility we’ve spent years building?

Those are not merely SEO questions.

They are website development questions.

If I were rebuilding this website

I wouldn’t begin with the homepage design.

I’d begin with the architecture.

1. Build the complete URL inventory

Identify every important historical and current URL before designing the new structure.

2. Create a redirect map

Every valuable old URL should have a clearly defined destination where appropriate.

No guessing.

No “we’ll fix redirects after launch.”

3. Establish one clean URL architecture

The next structure should be logical, predictable and capable of surviving future redesigns.

4. Build a proper content management system

Notices, events, faculty, announcements, gallery content and other frequently changing information should be easy for the institution to manage inhouse without being dependent on an external agency.

5. Turn admissions into a workflow

The enquiry form should become part of an actual admissions process.

6. Turn grievance handling into a workflow

Students should receive a reference number and have a clear mechanism for tracking their submission.

7. Fix the communication layer

Use institutional email addresses and keep every social media link current.

8. Fix broken sections

A Blog link should lead to a working blog.

An “online” chat should accurately represent availability.

A notice section should look current.

9. Build search architecture into the foundation

The next website should be designed around:

• Crawlability
• Indexability
• Canonical URLs
• Redirects
• Internal linking
• Structured data
• XML sitemap
• Clean information architecture
• Search-friendly content

10. Monitor it after launch

Launching the website should be the beginning of monitoring, not the end.

Important URLs should be monitored.

Search visibility should be tracked.

Forms should be tested.

Broken links should be detected.

And significant changes should be documented.

The biggest lesson from the KLE CBA website

After going through all of this, I don’t think the biggest problem is that the website has had bad designs.

It hasn’t.

Some versions were quite good for their time.

The bigger problem is that the website’s digital history hasn’t always been treated as an asset.

Every redesign creates a temptation to say:

“Forget the old website. Let’s build something new.”

That’s understandable.

It’s also dangerous.

Because the internet doesn’t forget quite as easily as we do.

A URL that has existed for years can have value.

A page can have backlinks.

A domain can have search visibility.

An old article can continue bringing visitors.

A PDF can be indexed.

A page can be bookmarked.

And all of that can disappear surprisingly quickly if a redesign is treated purely as a visual exercise.

So, what does this audit actually prove?

Not that one particular redesign caused every ranking drop.

Not that every technical problem caused a Google penalty.

And certainly not that the current website is worthless.

That would be an intellectually lazy conclusion.

What the historical evidence does show is much more useful.

KLE CBA’s website has experienced several major architectural changes over approximately 18 years.

Those changes have coincided with significant fluctuations in search visibility.

The site went from roughly 5 ranking keywords, to nearly 100, down to 1, back up to approximately 215, and then down again to around 80 in the historical data examined.

The current website also contains several operational and UX issues that deserve attention.

Those are facts worth investigating.

And that’s what a proper audit should do.

It should not manufacture certainty.

It should make you ask better questions.

After going through all of this, there is another question worth asking. And it is a question that would have sounded almost ridiculous a few years ago, but today it is completely reasonable.

So why not just build the next website with AI?

We now have AI tools that can analyse websites, write code, generate interfaces, create content, build responsive layouts and produce a remarkably polished website in a matter of hours.

So if we can identify all these problems and AI can help fix most of them, do we even need a traditional web development approach anymore?

Honestly, you absolutely can use AI to build the next website.

And that’s what makes the question interesting.

Modern AI tools can help create structured and maintainable code, identify errors, build interfaces, generate UI/UX concepts, analyse technical issues and automate an enormous amount of the work involved in developing a modern website.

That’s not something to dismiss.

It is one of the biggest changes the web industry has seen in years.

But AI is a tool.

And the person using that tool still matters enormously.

The experience of the developer determines what questions are asked, which solutions are chosen, what gets rejected, what gets tested, what gets tested again, and how all the individual pieces are brought together into one coherent system.

Two people can use exactly the same AI tools and produce completely different websites.

And this audit is a perfect example of why.

AI can generate a new KLE CBA homepage.

It can generate a beautiful admissions form.

It can create a modern navigation system.

It can write code for redirects.

It can even help analyse historical URLs.

But before any of that happens, somebody needs to understand what already exists.

Which old URLs matter?

Which pages have value?

What happened to the search visibility after previous migrations?

What should be preserved?

What should be retired?

What should be redirected?

What happens to an admission enquiry after the student clicks Submit?

What happens to a grievance after it is filed?

What happens to the existing search presence when the new website goes live?

Those are not questions that should be answered by blindly asking an AI tool to “build a modern college website.”

AI can help answer them.

It can accelerate the work enormously.

But somebody still needs to connect the dots, make the decisions, understand the consequences and take responsibility for the finished system.

And this is something I have learned very clearly from working with AI-assisted development myself.

Some of the projects I’ve worked on using AI tools have taken three or four months to reach where I wanted them to be.

Not because AI couldn’t generate the code quickly.

The code is often the easy part.

Good web development is not a race to generate code. Many people and companies fail to understand this fundamental fact about the AI tools.

It is a process of thinking, testing, changing, breaking things, fixing them, looking at the result again and asking:

“Is this actually the right way to do it?”

That’s where experience makes a difference. A big one.

AI can give you extraordinary capabilities. Experience tells you what to do with them.

And for a website with 18 years of digital history behind it, that distinction matters enormously.

The next KLE CBA website could absolutely be built with some AI assistance.

The real question is not whether AI can build it, or help us build it.

The real question is whether the person using AI understands what needs to be built, what needs to be preserved, what needs to be changed and, most importantly, what must not be broken along the way.

Because after looking at 18 years of this website’s history, the biggest risk isn’t failing to build something modern.

The biggest risk is building something modern and accidentally losing everything valuable that came before it.

One final thought

There is something I genuinely enjoy about auditing an old website.

You get to see the fingerprints.

You can see decisions made by developers years ago.

You can see technologies that disappeared.

You can see URLs that came and went.

You can see redesigns.

You can see recoveries.

You can see mistakes.

And occasionally, you can see something that worked surprisingly well.

That’s what makes this more interesting than a normal website review.

I’m not looking at one website.

I’m looking at 18 years of decisions.

And when you look at a website that way, the objective of a redesign changes completely.

You aren’t simply building the next website.

You’re taking custody of everything the institution has already built on the web. And thats the safest place to be for any company or an institution like the KLE CBA.

And if I were responsible for the next version of KLE CBA’s website, that would be my starting point.

Don’t just make the next website better.

Make sure it doesn’t forget everything the previous one already earned.