Growing Yuzool with Rank

I build SEO software, and my own site needs more qualified search traffic. That is a useful tension—and a reason to show the work before presenting a polished result.

This is a field log, not a claim that Rank caused a traffic increase. Its numbers below are a historical Tinylytics snapshot from July 1–11, not current traffic and not Search Console performance. The site, product pages and distribution have changed since then.

I use Rank on Yuzool to choose what to inspect, make controlled changes, and keep enough history to learn from the outcome. The current measurement status is included plainly; when comparable Search Console data has not been checked, I say so rather than infer a lift.

Historical baseline: July 1–11

In a Tinylytics review covering July 1 to the morning of July 11, 2026, the site recorded 428 page views from 386 visitors. Google was listed as the referrer for 46 visits. The main paid-product groups received 142 views; 59 of those views were from macOS devices. These are historical site-analytics observations, not Search Console clicks or present-day counts.

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

At that historical baseline, the immediate issue was not evidence of a broken checkout; there was too little qualified product traffic to evaluate conversion confidently. A sale or no sale in such a small sample would not establish the cause.

What I changed in the workflow: October 2

The work prepared for the next measurement window focuses on one user journey instead of adding another broad feature list:

• Added a browser-based Search Console Pages CSV opportunity finder. The report is processed locally; it does not connect to Google or upload the export.
• Connected that tool to a practical guide on diagnosing low CTR, a 20-minute weekly review, and a change-tracking method.
• Clarified the difference between a one-off free check and Rank’s paid, recurring Mac workflow: page/query context, reviewed SEO changes and follow-up history.
• Added Tinylytics event labels for tool starts, report downloads and Rank CTA clicks so the steps in the funnel can be distinguished after deployment.

This records the work in the site repository. It is not evidence that the changes have been deployed, indexed, or have increased traffic. Those are separate checks.

Measurement status: no lift claimed

As of October 2, I have not attached a comparable post-change Search Console export to this entry. I therefore cannot say that the new tool or content has improved impressions, clicks, rankings, product visits or sales. The next update should compare equivalent windows after the pages are live and have had time to collect data, and should note other changes that may have affected results.

The first useful evidence is not simply a larger page-view total. I want to know whether searchers who land on a relevant guide use the CSV tool, move to the Rank product page, and click through to checkout—and whether the target queries gain qualified impressions over time.

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.

The free Search Console opportunity finder now gives visitors a small version of the first step: export the Pages report, sort it locally, then inspect query intent in Search Console. It is not a live connection or a performance forecast.

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

The next update will use a comparable Search Console window after the pages are deployed and enough data has accumulated. Seven, fourteen and twenty-eight days are review checkpoints, not guarantees of statistical confidence. If the result is inconclusive—or if another change makes attribution impossible—that will be recorded as the result rather than edited into a success story.