Ciny AI

Website Optimiser audits your pages, links and mobile speed.

A page with a thousand readers and no enquiries is not a content problem.

Discuss availabilityWhat runs inside
LiveModule status

The Ciny team runs page audits, sitemap scans, internal-link analysis and mobile Lighthouse checks on demand. These checks ran on Ruh AI's site on 8 and 10 September 2026, with saved results. Funnel leak analysis, competitor research, real-user Core Web Vitals and automatic fixes are in build. Staged page release and before-and-after measurement are planned.

Explore 6 automations

Module overview

Make the next action clearer.

It is often the first page worth reviewing. Website Optimiser audits your pages, maps the internal links across a sample of your sitemap and runs mobile Lighthouse checks. The Ciny team runs each check on demand, and the results are reported to you without any change to your site.

Service scope

Is this the right fit?

Who this is for

Teams whose site gets attention but makes the offer, navigation or enquiry step difficult to understand or use.

What to bring

Priority URLs, access to the site workflow, known customer questions and any reliable visitor or form events. Instrumentation gaps come before optimisation claims.

What you receive

Page audits, a sitemap scan, internal-link analysis and mobile Lighthouse checks, run on demand by the Ciny team, with findings your team can act on. Staged release and the automatic fix-and-prove loop are planned.

Illustrative example

When form starts are recorded but submissions are not, first test the event path and the form itself. A design change cannot fix missing measurement on its own.

How to evaluate the work

Record the starting condition, change and comparison window. Keep real-user performance, lab measurements and enquiry outcomes distinct.

What runs inside

6 automations. Each one switchable on its own.

You pay for what you switch on. Each automation shows its status, so you can choose where to start.

Compare every automation
In build

Page Doctor

Funnel leak analysis is built as an operator tool on PostHog. It counts visitors, form started, form submitted and lead captured, and needs your events mapped to those names. Page diagnosis and fix prescriptions are planned.

Run by
Diane
How Page Doctor works
Planned

Page Drip Automation

Staged release of approved pages in waves is planned, and today your own frontend releases the pages the SEO module proposes, with human sign-off.

How Page Drip Automation works
Live

Content Audit Automation

Audits on-page basics, answer structure, readability and thin content across a sample of your sitemap, up to 50 pages per scan. Duplicate page detection and the refresh, merge or redirect verdicts are in build. Decaying page detection is planned.

Run by
Diane
How Content Audit Automation works
Live

Internal Linking Automation

Maps the internal links in and out of each scanned page, and Brand Social adds relevant links to new articles. A full interlinking plan with required anchors is available. Ciny does not edit links on existing pages.

Run by
Alex
How Internal Linking Automation works
In build

Page Speed Automation

Runs a mobile Lighthouse lab check on request and saves the four category scores, load timings and top opportunities. An experiment loop for Next.js codebases is built but has not run for a client. Real-user Core Web Vitals are in build.

Run by
Diane
How Page Speed Automation works
In build

Competitor Intelligence

A competitor site crawler and search share of voice are built but have not run on live data. Share of voice needs paid search data, which is switched off, and the first crawl needs agreed boundaries.

How Competitor Intelligence works
Hand-drawn website layouts on paper beside an orange pen.

From page review to a useful change

Make the journey easier to follow.

Inspect the pages visitors rely on, from understanding your offer to making an enquiry. Keep each proposed change tied to an observed problem.

  • Defined pages and journeys to inspect
  • Content, links and technical findings
  • Reviewed changes with acceptance checks
01

Start with the pages and journeys that matter.

An audit is most useful when its coverage is explicit. Agree which pages, templates and journeys need attention, what reporting is available and who can implement a change.

A specialist service page may need a clearer explanation of the engagement. A guide may need better links to the relevant service. A contact journey may need investigation because visitors cannot understand the next step. These are different starting points, even when they belong to the same website.

The audit is not described as unlimited or exhaustive unless that coverage is actually established. Record sampled pages, crawl limits and anything that could not be inspected.

02

Review the explanation before adding more design.

A visitor needs to recognise what you offer, decide whether it is relevant and find the evidence needed to continue. The page should answer those questions in a sequence that is easy to follow.

Review headings and main text together. A descriptive title cannot compensate for a page that never answers its central question. Avoid replacing specific explanations with broad statements about growth or transformation.

Offer and fit

Explain the service, who it is for and any scope boundaries that would change a buying decision.

Evidence and detail

Use approved process information, specifications or examples. Remove claims that the business cannot substantiate.

Next step

Make the destination and purpose of the next action clear. A button should not imply a working service that is not connected.

04

Investigate performance with the right evidence.

Lab measurements help reproduce a problem under a defined test setup. Field data, when available, describes real visits. Keep these sources separate and identify the page and conditions being measured.

A score is an observation, not an implementation plan. Connect the finding to the underlying asset or behaviour, then assess the proposed fix. Better performance does not independently guarantee improved search rankings or enquiries.

Examples of issues worth investigating
AreaWhat to inspectWhat to avoid assuming
LoadingLarge media, fonts and delayed main contentOne test represents all visitors
InteractionMenus, forms and scripts around common actionsA high score proves every control works
Layout stabilityReserved media space and late content changesA desktop check covers the mobile journey
Four people discussing work around a desktop monitor, with one pointing toward the screen.

Before implementation

Make the proposed change reviewable.

Show the problem, the proposed revision and the check that will confirm it works. Then agree who can approve and release it.

Review and implementation
05

Review the proposed page before implementation.

Live, Draft and Code views can support a focused discussion about the existing page and the proposed revision. They help distinguish an idea from an implemented change.

A useful change record identifies the affected page, the observed problem, the proposed adjustment and the check that will confirm it works. For a content issue, that check may be whether a missing buyer question is answered. For a broken link, it may be the destination and response.

Implementation follows the agreed source and hosting route. Confirm who can approve and release changes, preserve relevant existing content and review the actual page after release. A generated draft is not deployment evidence.

How review and release decisions work
06

Leave with a practical order of work.

Prioritisation should reflect the effect on users, the strength of the evidence and the effort or dependency involved. A broken enquiry route may deserve attention before a cosmetic refinement.

Separate a confirmed issue from a hypothesis. Record what needs more data and what can be checked immediately. Agree the next set of changes rather than treating a long audit document as the result.

Where reporting is available, review the affected pages over comparable periods after implementation. Where it is not, report the confirmed functional improvement without inventing a commercial uplift.

The system behind it

Audit the pages. Hand over the findings.

Every module runs the same five moves: read the signals, decide what is worth doing, make it, hold it for approval, then measure what it changed. The signals and the output differ. The discipline does not.

  • one loop, five moves
  • built for Ruh AI first
  • approval controls depend on the workflow
Explore the delivery process

Signals in

  • Page HTML
  • Sitemap and robots.txt
  • Lighthouse lab results

Diane · Audit the pages. Hand over the findings.

What each check returns

  • page · title, meta, H1, alt text
  • links · in and out per page
  • mobile · Lighthouse scores

Automation roles

The responsibilities behind the workflow.

Diane owns this module. Julia does the research inside it, the same way she does inside all three, so every brief starts from your data rather than a content calendar template.

  • Diane

    Module Lead

    Reads the page audits, link analysis and Lighthouse results, and keeps each one in the saved audit history.

  • Julia

    R&D

    Can draft an improvement plan from the saved audits on request. That step is built and has not yet run for a client.

  • Alex

    Pages

    Adds relevant internal links to new articles. Changes to existing pages stay with your team.

Scope notes

Good to know.

  • The Ciny team runs each check on demand, and a scan covers a sample of up to 50 pages.
  • Your developers apply the fixes, or the Ciny team does as custom work. Staged release and before-and-after measurement are planned.
  • Funnel analysis reads the events your site records, so analytics come first if they are not set up yet.

Connected work

Work in practice

Read the evidence. Then talk about your business.

Two stories with different evidence levels. Read each source and its limits.

All case studies

First-party measurement

Ruh AI

Organic leads, with the evidence attached.

Weekly organic leads rose from 6 in early July to 20 in the week of 24 August 2026. August paid spend was $0.

  • PostHog lead events, test entries excluded. Google Ads. August 2026.
  • Measured on our own site. Observed results, not a guarantee or proof of causation.
Discuss your goals
Weekly organic leads
6 to 20
Evidence
First-party
Read the study

Published Ruh AI customer story

Rapid Innovation

A more connected marketing workflow.

Ruh AI reports 37% more leads for Rapid Innovation after introducing AI-supported research, publishing and lead qualification.

  • Source: the published Rapid Innovation story on ruh.ai.
  • Publisher-reported results. Measurement period and methodology are not disclosed. Not a measured Ciny result.
Discuss your goals
Reported leads
+37%
Source
Ruh AI story
Read the study

These studies explain the wider work behind Ciny. They do not establish results for every capability. Live, Available, In build and Planned labels still apply.

Switch on Website Optimiser. Leave the rest off.

Modules are switched on and off per account. Start with one, add the others when the first has earned it.

Book a walkthroughExplore the case studies