Case Study: Pharmaceutical Site Boosts Speed and Conversions in 10 Days

Quick Summary (If You Are in a Hurry)

A Serbian company selling herbal and honey-based remedies had its catalog stuck on a broken custom system. After my fix, mobile bounce fell from 80% to 35% and time on the site more than doubled.
She called to run an urgent 30%-off sale but could not change prices, because the developer had ignored her for two months.
The real cause was a custom JavaScript system only that developer could use, plus heavy images and no mobile layout.
I made the old site usable within days, then rebuilt it on WordPress so the owner would never be trapped by one developer again.

The lesson: if only one person can change your website, you do not control your business.

Full Case Study

At a Glance

Client: a Serbian company selling herbal and honey-based natural remedies as an online catalog (no online payment, orders by phone or email)
Platform: a custom JavaScript CMS, then rebuilt on WordPress (TagDiv Newspaper theme)
Service: emergency mobile fix and WordPress replatform
Timeline: 2015, about 10 days of core work
Headline results: the catalog finally worked on phones, mobile bounce fell from about 80% to about 35%, and time on the site more than doubled, from about 1.5 to about 3.5 minutes

Client and Context

The client imported and sold herbal and honey-based natural remedies, the kind sold over the counter without a prescription. It bought from suppliers abroad and sold only within Serbia, shipping by post and courier.

The website was an online catalog, not a store. Each product had its own page with a price, but there was no online payment, so customers ordered by phone or email. The site ran in two languages, Serbian for customers and English for its foreign suppliers and partners.

The owner was an older woman with no technical background. Her team was three people, herself and two colleagues in marketing and sales. None of them could work on the website.

The site was the company’s shop window, so every visitor who could not use it on a phone was a lost sale.

The Problem

When the owner first contacted me, her problem was urgent. She needed to put several products on a 30%-off sale, because they were not selling and their shelf life was running out. But she could not change the prices herself, and the developer who built the site had ignored her calls and emails for two months.

None of the three women knew anything about websites, so they could not even guess what was wrong. They only knew they were stuck.

The site itself had serious problems:

It ran on a custom system that only the original, now-absent developer could use.
It did not work on phones, even though about 70% of visitors used them.
Product images were 1 to 2 MB each, which made pages load slowly.
The navigation was poor. The only contact link sat in the footer, so visitors who did not scroll could not find how to reach the company.

Each problem cost the business directly:

The owner could not run her own sale or update her own prices.
Mobile visitors could not browse the catalog or place orders.
Visitors who did arrive often could not find a way to make contact.

The Audit and Diagnosis

The real problem was not one broken feature. It was the platform itself. The site ran on a badly built custom system written in JavaScript, and only the developer who made it could operate it.

The owner gave me access to the hosting and the system, so I could see the real state of the site instead of guessing. The findings were clear:

The system had no way to compress or resize images, and no simple way for a non-technical person to upload them. Every change needed the developer. I confirmed this inside the system itself.
The product images were far too heavy and slowed every page. I found them by opening the file structure on the hosting.
The site had no mobile layout at all, yet Google Analytics showed about 70% of visitors were on phones.

One insight shaped everything. The company’s products had almost no competition in Serbia, so traffic was never the problem. Visitors arrived and simply could not use the site.

The owner found it hard to put the faults into words. So I recorded a short video walking her through the system’s problems. After watching it, she agreed to rebuild on WordPress rather than patch the old site any further.

The Solution

My plan had two parts. First, make the existing site usable at once. Then rebuild it on a platform the owner could control.

I stabilized the old site in about three days:

Set the discounted prices the owner urgently needed for her sale.
Re-cropped and optimized every product image in Photoshop, cutting them from 1 to 2 MB down to about 120 to 150 KB.
Made the site responsive with CSS changes, so it adjusted to fit phone screens.
Fixed the navigation so the contact details were easy to find, not hidden in the footer.
Cleaned up the weak product texts.

After these fixes, the site worked on phones and, as the owner put it, the phones started ringing.

Then I built the permanent replacement on WordPress:

Built a demo WordPress site in a private /dev/ folder (a safe area to build without touching the live site), on the TagDiv Newspaper theme, shaped around the owner’s feedback.
Set up a fresh, dedicated Hetzner server, managed with Plesk, and moved the finished demo onto it.
Installed caching and security plugins and tuned the site for speed.
Set up email-marketing foundations with MailChimp, which the owner had never used before and was keen to use later.

I also set the company up to create its own content. I researched the Serbian market and built a simple keyword brief in a Google Sheet, with columns for the main phrase, supporting phrases, and related topics.

I trained the company’s writer, a doctor who already wrote for the site, to use it, and recorded a how-to video for her. To speed things up, I also wrote some posts myself, which the doctor reviewed and approved before they went live. I briefed the company’s packaging designer on how to photograph the products.

When the foundation was ready, the company hired an in-house developer to run the site. I handed over the logins and a written PDF guide on how to continue, and the new developer built the catalog out from my demo. I did not log in again.

The Results

The results showed up on the old site first, even before the new one launched. The catalog finally worked on phones, mobile bounce fell from about 80% to about 35%, and time on the site more than doubled, from about 1.5 to about 3.5 minutes.

I measured each of these in Google Analytics on the improved old site, after the responsive fix, the lighter images, and the new articles, but before the WordPress version went live:

Mobile bounce rate dropped from about 80% to about 35%. Bounce rate is the share of visitors who leave after seeing only one page.
Average time on the site rose from about 1.5 minutes to about 3.5 minutes.
Product images dropped from 1 to 2 MB to about 120 to 150 KB after optimization.
Page-load speed improved by about 20 to 25% once the images were optimized, guided by PageSpeed Insights. The last speed issues only cleared once the site moved to WordPress.

The content helped as much as the technical work. The doctor’s new articles, laid out for mobile reading with short sections and lists, kept visitors far longer and began drawing new organic search traffic before the relaunch.

The business outcome mattered most to the owner. She went from stuck and dependent on a developer who would not answer, to a fast, modern site she and her team could finally control.

Tools and Methods Used

Diagnostics: Google Analytics, which revealed the 70% mobile traffic, and PageSpeed Insights.
Performance: Photoshop for image optimization, a caching plugin, the TagDiv Newspaper WordPress theme, and a dedicated Hetzner server.
Safety and process: a security plugin, a private /dev/ build area, and Plesk for managing the server.
Content and research: SEMrush, Ahrefs, and SEO browser extensions for keyword and competitor research, plus a Google Sheet keyword brief.
Email: MailChimp for the email-marketing foundation.

Are You Facing a Similar Problem Right Now?

It is stressful when you cannot change your own website, or when it works on a computer but falls apart on a phone. Often the real issue is the platform and a choice made years ago, not anything you did wrong. Problems like these can almost always be solved with clear, calm steps.

If you want calm, simple help to understand your own website, you can contact me.