Growing Yuzool with Rank

I build SEO software, and my own site needs more search traffic. That is a useful tension.

It would be easy to write a polished story in which one title change produces a dramatic graph. That is not where Yuzool is today. The site has a stronger structure and much clearer product pages than it did a few weeks ago, but traffic is still small and there have been no direct site sales so far this month.

This case study begins before the pleasing result. I am using Rank on Yuzool to decide what deserves attention, make controlled changes, and keep enough history to learn from the outcome. I will update this page when comparable 7-, 14-, and 28-day data exists.

The July 11 baseline

From July 1 to the morning of July 11, Tinylytics recorded 428 page views from 386 visitors across Yuzool. Google referred 46 visits. The main paid-product groups received 142 views, but only 59 of those views came from macOS devices.

That distinction matters. Yuzool sells mostly Mac software. A visitor reading a Rank page on Windows may still be researching for a Mac, but device-qualified product traffic is a better planning signal than the site's total view count.

• Rank pages: 34 views from 32 visitors
• Dispatch pages: 62 views from 52 visitors
• Relay pages: 37 views from 31 visitors
• Only 28 visitors viewed more than one page across the site
• Google sent eight visits directly into the main paid-product groups

The immediate problem is not an obviously broken checkout. There is simply not enough qualified product traffic to evaluate conversion with confidence. At this baseline, one sale or no sales can both happen without proving very much.

The first decision: concentrate

A studio with several products can accidentally market none of them. Every app gets a new page, a short announcement, and a place on the homepage, but no single product receives enough repeated attention to become familiar.

For this experiment, Rank is the lead product. It solves a recognisable problem, the audience can be identified, and Yuzool itself provides a real test site. Dispatch and Relay still have useful pages, but the next set of demonstrations, outreach, and SEO observations will primarily lead back to Rank.

The Rank workflow I am using

I begin by syncing Search Console and reviewing page and query performance. I am looking for evidence of existing demand: impressions with weak CTR, useful queries around positions 8–20, pages that are declining, and product pages that could connect search intent to a clear next step.

Then I add crawl context. A page can underperform because its title misses the intent, because its content is thin, because internal links do not support it, or because a technical signal is wrong. Search data identifies the opportunity; the page audit helps explain what kind of work might be justified.

What I will change first

The first round is deliberately small:

• Use one clear Rank demonstration as the destination for people who need to see the app in motion.
• Connect the demonstration, product page, buyer guide, and this case study with explicit internal links.
• Promote one concrete workflow rather than the entire feature list: find a page worth improving, ship one change, and measure it.
• Track product views and buy clicks separately so traffic and conversion are not confused.
• Record subsequent SEO changes in Rank and review them after comparable windows.

The aim is not to change every page at once. If several titles, sections, links, and calls to action change together, any later movement becomes difficult to interpret.

What will count as progress

Sales are the final business signal, but they are too sparse to be the only feedback. The earlier indicators are:

• more Google visits landing directly on Rank and its buyer-intent pages
• more visitors moving from the demonstration or case study to the product page
• more qualified Mac visitors reaching the checkout
• improved CTR for the specific queries and pages changed
• repeatable acquisition sources rather than isolated launch spikes

A result can also be negative. If impressions grow but visitors do not explore the product, the page may be attracting the wrong intent. If buy clicks occur but purchases do not, the offer, trust, price, or checkout needs attention. Rank helps preserve that distinction.

Why publish the baseline?

Small software businesses are often presented after the graph becomes impressive. The earlier stage is more useful to me: deciding what to do when the data is thin, resisting the temptation to manufacture certainty, and building a process that can survive a quiet week.

Rank is not being used here as a magic traffic button. It is the workspace for making better-supported decisions and remembering what happened. That is a less dramatic promise, but it is the one I want the product to keep.

Update schedule

I will add the first update after a comparable seven-day window has accumulated, then revisit the work at 14 and 28 days where the volume supports a useful comparison. If the result is inconclusive, that will be recorded as the result rather than edited into a success story.