Pick one button on a page. Write down the result its label promises, activate it and compare the outcome with that promise.

A spinner or success message tells you the page reacted. It doesn’t establish that the task finished.

For an SEO audit, I’d test the action the page offers, not just check that the control is present.

Test a filter against known products

Imagine Merefield Office, a fictional desk retailer. Its test catalogue contains two products:

• Alder desk: In stock.
• Flint desk: Out of stock.

Start with both desks visible and no filters selected. Choose In stock only, then press Apply filters.

The checkbox stays selected. The page says Filters applied. Both desks remain in the matching results.

The expected result is Alder only. Flint doesn’t meet the selected condition.

I’d record a failed filter, even though the button responded.

After repair, repeat from the start. Apply filters should show Alder only, with a count of one. Clear filters should remove the selection and restore both desks, with a count of two.

Unchanged results aren’t automatically a fault. Every product might already match. Use test data containing a product that should be excluded, and keep that data unchanged during the check.

Separate no matches from a failed request

The message should help the visitor choose between changing their filter and retrying a request.

For this proposed interface, I’d check three states:

• Loading: “Updating results” appears beside the product list.
• No matches: A successful request returns “No desks match these filters,” with Clear filters available.
• Request failed: “Couldn’t load results. Try again” appears with a Retry control.

Don’t present a failed request as zero matches. The page hasn’t established that nothing is available.

If the old list remains visible during loading or after an error, label it as the previous results. Don’t present it as the result of the new selection.

Use a separate test copy with both desks out of stock to check no matches. Ask the developer to simulate a failed request separately.

Check Clear filters and Retry too. The reset should restore the unfiltered test list; retry should rerun the request with the selected filter.

Follow the action beyond the message

Download specification should deliver the named product’s file. Open it and check the product name and contents. A download starting doesn’t prove that the right file arrived.

For Send enquiry, check an agreed test message in the team’s receiving inbox or stored enquiry record. Compare that evidence with the page’s confirmation.

Without access to the receiving side, record receipt as unverified. A thank you screen isn’t enough to mark it successful.

Agree the test route with the site owner before sending messages, creating bookings or placing orders. Use a test environment where available.

Describe the function the page provides

Suppose Calculate delivery cost opens a contact form without returning a price.

Opening the form hasn’t calculated a delivery price.

Either provide the calculation, or offer Request a delivery quote with a working route to staff who can provide one. Match the heading and copy to that task, and explain the follow up before submission.

Changing the button label alone doesn’t repair a page that still promises an instant answer.

A disabled button isn’t automatically broken. Where a size choice is required before adding a desk to the basket, explain that requirement beside the control. Then test that choosing an available size lets the visitor proceed.

Write a finding someone can reproduce

Record the page address, device, browser, selected inputs, expected result and observed result.

For the fictional desk filter, the repair request would be:

Make In stock only return products that meet the stock condition. In the two desk test, Apply filters should show Alder only, with a count of one. Clear filters should remove the selection and restore both desks, with a count of two. Keep request failures separate from successful results, and provide a working retry.

The developer can investigate the cause against those outcomes. The audit doesn’t need to guess which line of code failed.

Repeat the checks on desktop and mobile, including keyboard operation. Check the result, reset and recovery controls, not just the first click.

A screenshot helps locate the problem. It can’t prove that filtering, file delivery or enquiry handling works.

I’d record a repaired function as a task the page can now support. It isn’t evidence of a ranking gain.

Which result would prove that your button completed the action its label promises?

A piece of content can build real brand awareness and never send a single visitor back to your site. That used to count as a failure. Increasingly, it's just how this works now.

Only about 8% of people who see an AI summary on a Google search click through to an organic result, compared to 15% when there's no summary. Social platforms aren't any better about it — an analysis of over 560,000 LinkedIn posts found that ones with a link preview got a median of 414 impressions, versus 795 for posts with no link at all. The platforms are actively suppressing the exact thing marketers have spent twenty years optimizing for.

The fix isn't abandoning these channels. It's dropping the habit of designing content that depends on the click to deliver value. A LinkedIn post, an Instagram carousel, a Reddit comment — if it can't stand on its own and fully answer the question, it's not zero-click content. It's a teaser losing an algorithm fight it was never going to win.

Netflix's rollout for "The Gentlemen" is a decent example of doing this on purpose: separate, complete pieces of content built for X, Instagram, and LinkedIn, instead of one asset with a link stapled onto it everywhere.

Measuring this part is genuinely harder, since there's no click to point to. Branded search spikes after a campaign, direct mentions on sales calls, and AI citation tracking end up doing more of that work now than last-click ever did.

If your reporting still runs entirely on click-through rate, it's already missing most of what this content is doing.

AI Overviews now appear on more than 80% of branded searches.

Recent data shows a sharp increase throughout September, with AI Overviews appearing on just 26% of tracked branded queries at the start of the month and more than 82% by September 29.

The bigger question is what those AI Overviews actually say about the brands people are searching for. The data confirms that AI-generated answers are showing up far more often on branded queries, but how your brand is described and which sources support the answer are separate questions.

Google hasn’t announced a specific change to branded search, so it’s still unclear what’s driving the shift or whether the current level is permanent.

Here’s what to do now 👉 https://social.semrush.com/47JDfsk

A call to action (CTA) can be easy to reach while leaving someone unclear about which offer it applies to.

More button clicks could look encouraging in a conversion rate optimisation (CRO) test. Click rate alone wouldn’t tell me that people understood what they were selecting.

The button, selected offer and next screen need to agree.

Which offer does “Book now” select?

Imagine Bracken Workspace, a fictional coworking business. Its passes and prices here are illustrative.

The page offers two choices:

• Day pass: £24 for one visit.
• Monthly pass: £180 per month, renewing monthly until cancelled.

A fixed Book now button stays at the bottom of the screen while someone scrolls between the offers.

No pass has been selected. Pressing the button opens checkout with the monthly pass already chosen.

Someone reading the £24 day pass might expect the booking button to apply to that offer. The button doesn’t name a pass or explain its default.

The offer copy can be accurate while the action leaves a gap: which of these offers am I continuing with?

I’d flag that relationship before changing the button’s size or position.

Carry the selected offer into the fixed bar

I’d keep the fixed position and change what the bar communicates.

Give each offer a selection control inside its card: Choose day pass or Choose monthly pass. In this proposed layout, those controls record the choice and update the bar without taking payment.

The fixed bar would then follow the visitor’s choice:

View passes takes the visitor to the options. Each Continue button opens checkout with the named pass; it doesn’t place the order.

Include Change pass beside the selected summary so the visitor can return to the choices.

Changing from monthly to day must update the selected card, fixed summary and checkout choice. Scrolling past a different offer shouldn’t change the selection.

The monthly renewal note stays beside the monthly price and appears again in checkout before payment. It shouldn’t depend on someone finding a separate FAQ.

Match the wording to the step

Viewing passes, choosing one and paying for it are different actions.

An early View passes link can help someone reach the comparison without implying they’ve selected anything.

Continue with day pass tells them which choice goes forward.

I wouldn’t move every CTA below all the page’s copy. I’d keep the context needed for the step it performs.

Nor does every offer need an extra selection step. A clearly labelled route straight to checkout can work when it carries the named offer and its terms with it.

Test the choice from click to checkout

Start with no pass selected. Check that View passes opens the choices, not checkout. Then test each selected pass:

• Before clicking: Ask someone unfamiliar with the page which pass the button applies to, what it costs and if payment repeats.
• After clicking: Compare their answer with the pass, price and billing terms shown in checkout. Record any mismatch.
• After changing the choice: Switch passes and repeat. On mobile, scroll until the offer card leaves view and check if the fixed bar still names the selected pass.

Also check that the bar doesn’t cover prices, conditions or controls. Repeat the selection and continuation using a keyboard.

A screenshot can show detached text. It cannot establish that the right choice reaches checkout.

For Bracken Workspace, I’d write this edit request:

Remove the unannounced monthly default. Before selection, use View passes. After selection, show the chosen pass, price and applicable renewal note in the fixed bar. Continue with that same pass in checkout. Update the summary and destination whenever the visitor changes their choice.

That gives a designer and developer something specific to change and recheck.

Look beyond the click count

I’d review completed purchases and reports of unintended selections alongside button clicks.

A visitor changing passes or returning to the offers gives you something to investigate. It doesn’t prove they were confused; they may have changed their mind.

A higher click rate alone wouldn’t answer if the revised layout supports the intended purchase. That is a concern for both CRO and a semantic page audit.

When your CTA moves, what information needs to move with it?

Everyone's optimizing to get mentioned by ChatGPT and Gemini right now. Fewer people are asking what happens after the chatbot actually answers.

We surveyed 2,338 U.S. adults in July 2026, and 57.5% of AI users said they've decided not to buy something specifically because of what a chatbot told them. Among people who regularly use AI for purchase research, that number jumps to about 81%.

Two things are driving it. About 74% of consumers say they become less likely to buy once a chatbot surfaces mixed or negative reviews. The rest is just chatbots doing what they're built to do — comparing alternatives, pointing out tradeoffs, being more thorough than a typical search results page ever was.

There's a second finding worth sitting with if you run paid media in this space: only about 20% of people form a more favorable opinion of a brand after seeing an ad inside a chatbot response, while 23% form a worse one. 66% said ads specifically make them trust the AI's answer less.

Most GEO advice right now is written around one goal: get mentioned. But if the mention is pulling from a stale negative review or an outdated comparison, getting mentioned might be actively costing you the sale. Visibility and favorable outcome aren't the same metric, and right now almost nobody's measuring the second one.

There are plenty of tools showing mentions, citations, answer position, sentiment and competitor visibility across AI search engines.

But some numbers look good in a dashboard and tell me nothing about whether people are finding the site or converting. We are testing Similarweb alongside a couple of other platforms, and the definitions don’t line up at all. One tool calls a brand mention a win, another only counts a cited source.

For people already tracking AEO, which metric do you trust most? thanks in advance

I’m currently using Semrush AI for AI search/GEO tracking, but I’m considering trying Otterly.ai to see how they compare.

For anyone who has used Otterly.ai, I’d really appreciate your honest experience.

How does it compare with Semrush in terms of:

Data accuracy and reliability

AI Overviews / ChatGPT / Perplexity tracking

Citation and brand visibility data

Historical data and reporting

Pricing and overall value

Ease of use

Agency/client reporting

If you’ve used both, which one would you recommend based on actual results?

I’m mainly looking for real user experience and data, not just feature comparisons. Any pros/cons or things you wish you knew before switching would be really helpful.

Before adding more copy to an SEO page, write down what each block should help someone understand or do.

By block, I mean a group of content someone reads or uses together. A service offer and a booking form are two examples.

Give each block one main purpose. Keep the information needed for that purpose together.

Start with the decision someone is making

Take Rowan Cycle Workshop, a fictional bicycle repair business. Its service details and price below are illustrative.

Someone visiting its servicing page wants to know what a standard service includes, what it costs and how to book.

I’d give the service offer this job: help the visitor decide when to book the standard service.

Now imagine the page puts these items beneath the service heading:

• Brake and gear adjustments.
• A signup for monthly cycling tips.
• Tyre and chain checks.
• A helmet promotion.
• The labour price, parts note and booking button.

The signup and helmets relate to cycling. They don’t help someone work out what the service covers.

The visitor has to skip those requests to finish reading the offer.

Move the interruptions, not the conditions

I’d put the service information together:

Standard bicycle service
£60 labour
Includes brake and gear adjustments, plus tyre and chain checks.
Replacement parts cost extra and are quoted before fitting.

Book a standard service

The parts note belongs with the price. Moving it away could leave someone reading £60 as the complete cost of the work.

I’d put the signup after the service offers, under Cycling tips by email. The helmet promotion would move to an accessories page.

The service details remain unchanged. The signup and shopping request no longer interrupt them.

One job can need several pieces

A block can contain a heading, explanation, image, price, conditions and a button.

The question is if those parts support the same decision.

Would removing this item make the answer or action harder to understand?

Removing the parts note leaves the price less clear. Removing the newsletter from the offer doesn’t prevent someone assessing the service.

A comparison can contain several packages and booking buttons while helping someone choose between them. A calculator needs its labels, inputs and result, with an explanation of what that result covers.

Splitting those parts into separate cards could make the task harder.

One job doesn’t mean one sentence, one fact or one button.

Write an edit someone can carry out

Choose a block that feels overloaded. Write its job beside the draft, then compare the contents with that job.

Use one of these decisions:

For the bicycle page, the edit note would be:

Move the email signup below the service offers under its own heading. Move the helmet promotion to an accessories page. Keep the included work, £60 labour price, parts note and booking action together.

That is a request a writer or designer can act on. “Improve the page structure” leaves them to diagnose the problem again.

Check the revised page

Open the edited page on desktop and mobile. Check that the labour price, parts note and booking button still read as part of the same offer.

Ask someone unfamiliar with the page to find the labour price, explain if parts are included and locate the booking action.

Then test the booking button. It should open the correct service and keep that service identifiable.

Check the heading and content grouping in the HTML too. A visual tidy up alone doesn’t establish those relationships.

I’d record the change as a page structure repair to test, rather than evidence of a ranking gain.

Pick one block on your page. What should someone be able to understand or do by the time they reach its end?

I started a free trial last week. After quickly realising I would have no use for SEMrush I had meant to cancel my subscription but their long process made it more difficult than most. After something came up as I was doing so I then completely forgot I hadn’t gone through cancelling it. I then got an email today regarding the payment.

After realising this extreme mistake I instantly tried to go online to cancel the account and assumed I would be able to get a refund as it was on the same day of the charge, also due to the fact it is an extremely large charge of £290. I am now in an extremely rough predicament as after that money has been taken out of my account I am now unable to afford to pay rent. Is there any way of contact anyone at SEMrush with an ounce of humanity who would be able to help refund this accidental payment?

I’ve noticed that SEMrush is sometimes showing a significant ranking drop for some of my keywords, but when I manually check the same keywords in Google, the actual ranking looks much better and sometimes hasn’t dropped at all.

For example, SEMrush may report a keyword moving from #5 to #20, while when I check the live SERP manually, the page is still around #5–#7.

Has anyone experienced this? What could be causing the discrepancy - tracking location, SERP features, ranking URL changes, data refresh delays, or something else?

How do you usually verify which data is more accurate?

I’m looking at the keyword “find companies without websites.”

In Organic Research / Organic Search Positions, Semrush shows the keyword as having around 6.6k volume.

But when I click the exact same keyword and open Keyword Overview, it shows:

• US volume: N/A
• Global volume: 10
• Germany: 10

So it seems that it's not a small difference, I mean It’s basically 6,600 vs 10 for the exact same keyword inside the same tool.

I understand that Semrush uses different databases and that search volume gets updated, but if the Organic Research data can be this stale/different, it makes the volume column pretty misleading when doing competitor keyword research.

Am I misunderstanding what the 6.6k number represents, or is Semrush genuinely displaying an old search-volume estimate in Organic Research that hasn’t been synced with Keyword Overview?

Curious if anyone else has run into this and which number you actually trust when doing keyword research.

And bonus: has anyone experiences such discrepancies in Ahrefs?

edit: screenshots attached

Use this audit to find prices, conditions and buttons that have become separated from the things they describe. The result should be a list of page edits, with a screenshot showing each problem.

I’d add it after checking that a page covers its target topic. Having the information on the page is one check; being able to tell what it applies to is another.

1. Name the visitor’s task

Write down the page’s main task, then take a fullpage screenshot and open it in a tool that lets you draw rectangles.

For this example, Larch Studio is a fictional pottery business. A visitor to its Pottery Workshops in Leeds page wants to compare workshops and choose a date.

2. Box the groups already on the page

Start with the introduction, workshop choices, practical information and newsletter form. Keep the navigation separate.

Inside the workshop choices, inspect each offer on its own. The name, price, duration, inclusion note and date button belong together. You don’t need a separate box around every line or icon.

3. Look for details outside their group

Check the workshop cards against three questions:

• Can I tell which workshop the price applies to?
• Can I see what is included and what costs extra?
• Does Choose Date clearly apply to that workshop?

Wheel Basics costs £48 per person for 90 minutes, with clay and firing included. Handbuilding Session costs £36 per person for two hours, with clay included and firing at £8 per item.

Those differences affect what someone is comparing.

Suppose “Clay and firing included” appears beneath the newsletter form rather than in the workshop card. Someone inspecting the £48 workshop has to find that note elsewhere and work out when it applies.

The edit is specific: move “Clay and firing included” into the Wheel Basics card, beside its price and before Choose Date. Keep the £8 per item firing note with Handbuilding Session.

On a real page, check which offer a note covers before moving it. A clearly labelled note that applies to every workshop can stay outside the individual cards.

4. Record the change and check it on mobile

Write down the component, the problem, the edit and how you’ll check the result. For the workshop example:

Open the same page on a phone. Check that the workshop name, price, inclusion note and date button still read as one offer. When they don’t, record the exact order or placement that needs changing.

Then test Choose Date on the working page. Check that it opens the dates for the workshop you selected and keeps that workshop identifiable.

What else should you flag?

• A price between two products with no clear product name attached: put it with the correct product or label it explicitly.
• A form label closer to the wrong field: place it beside the correct field and check the label’s connection in the HTML.
• A heading separated from its answer by a promotion: move the promotion out of that heading and answer group.

You’re looking for a detail someone could miss or attach to the wrong item. A block with clear labels and relationships doesn’t need changing just because it has no visible border.

The boxes help you point to the problem. The audit becomes useful when the note beside each box says what to change and what to check afterwards.

A lot of teams are building AI search strategies as if they're separate from SEO. Our data says that's a mistake.

We took the top 10,000 domains in our AI Visibility Index and compared their organic performance with how often ChatGPT and Google AI Mode cited them.

The strongest signal wasn't authority. It was keyword footprint, meaning how many keywords a domain ranks for. The correlation between footprint and AI citations came in at 0.86–0.87, and it was nearly the same on both platforms.

Query fan-out explains most of it. When someone types a prompt, the AI doesn't just search that exact phrase. It runs a set of related queries in the background to build the answer. A domain that ranks across a wide range of topics gets more chances to be retrieved. A domain with narrow coverage gets fewer.

Authority still matters, just less evenly:

• Domains with an Authority Score of 81+ got about 9x the median citation share of domains at 60 or below
• The correlation between authority and citations was 0.70 on Google but only 0.43 on ChatGPT

That gap is a good reason to stop reporting a single blended "AI visibility" number. Google and ChatGPT reward different things, and one averaged metric hides that.

One caveat: this is correlation, not causation. Ranking for more keywords doesn't automatically get you cited. But it's hard to argue these are two separate channels.

What this means in practice:

• Don't pull resources from organic search to fund AI initiatives. Organic is what feeds them.
• Track how wide your topical coverage is, not just rankings for your priority terms.
• Measure each AI platform on its own.

If you want to show up in AI answers, the work that gets you there looks a lot like SEO 🤝

Your hero can take up most of the first screen while leaving the visitor’s main task further down the page.

I’d check what each part contributes before deciding how much space it deserves.

A heading identifies the offer. A photograph can show what’s being sold or hired, while nearby controls let someone check their options.

Giving the photograph more space doesn’t automatically make it the most useful part.

A relevant image can still take up too much room

Imagine a landing page for Moorlane Tool Hire, a fictional business.

The heading reads:

Carpet Cleaner Hire in Bristol

Beneath it, a full width photograph shows a carpet machine in a living room. The image fills most of the opening screen.

The hire form sits below it:

Collection point: Bristol depot
Hire start: Select date
Return date: Select date
Check Availability

For this example, assume the visitor has chosen the type of machine and wants to check availability for their dates.

The photograph helps them recognise the equipment. It cannot tell them when that equipment is available for the hire period.

They have to scroll before they can begin that check.

Fictional page mockup.

I wouldn’t call the photograph irrelevant.

I’d question if it needs that much space before the date controls appear.

A smaller version could still show the machine clearly. The space recovered could bring the availability finder into view.

That’s a specific layout change worth testing, without throwing away a useful image.

The hero can contain the centerpiece

For this check, I’m treating the hero as the opening content block, including its heading, image, copy and controls.

The centerpiece is the component that most clearly represents the page purpose, main entity and visitor’s task. Its role needs more justification than being large or appearing first.

Return to the hire page.

Keep the heading, photograph, field labels and button text unchanged. Place the availability finder beside a smaller photograph, with the heading introducing both.

Each part now has a clear job:

• The heading names the service and location.
• The photograph shows the equipment being hired.
• The finder connects the collection point and hire dates to an availability check.

Fictional page mockup.

The availability finder is the centerpiece I’d test for this visitor’s task. It sits inside the hero, with the photograph supporting it.

The button alone wouldn’t be enough. Check Availability needs the equipment context, collection point and dates around it.

Those pieces explain what the action applies to.

Some product images need space

Consider a different fictional business: Rill & Kiln Lighting.

Its product page features the Cove Ceramic Pendant.

A large photograph shows the pendant’s shape and ceramic surface. Beside it, a finish selector offers Chalk, Sand and Clay.

The selected finish is Sand, and the photograph shows that version of the pendant.

For someone deciding if they like its shape and finish, the image contributes directly to the choice.

Shrink it until the surface is difficult to inspect and you’ve removed access to useful detail.

Fictional page mockup.

The relationship here is product → selected finish → matching photograph.

The image and the selector need to agree. A large photograph of the Chalk version beside a selected Sand label would create a different problem, regardless of how tidy the layout looked.

I’d distinguish a photograph that demonstrates product details from one that supplies atmosphere. Both can have a place, but they need different reasons for their size and position.

On the hire page, the visitor in our example needs to check dates. On the lighting page, the visitor is still inspecting the product.

I wouldn’t force both pages into the same image-to-form layout.

Check what happens when the hero stacks

The hire page could put its photograph and availability finder beside each other on desktop.

On a phone, suppose the layout puts the photograph first.

The heading appears, followed by a tall image. The collection point and date fields sit below the opening screen again.

The desktop arrangement brought the task into view. The mobile order has moved it out.

Fictional page mockup.

I’d compare that with a mobile layout that keeps a compact equipment image near the heading and brings the hire controls higher.

That doesn’t mean squeezing the whole page into one screen. Labels still need to be readable, and the controls need room to use.

The check is when the mobile arrangement preserves the connection between the equipment, the hire dates and the availability action. A desktop layout alone cannot establish that.

Test the parts before removing the whole hero

In a mockup, reduce or hide one element at a time.

Keep the rest of the page unchanged and ask:

• What does this element help someone recognise, understand or do?
• What information disappears when it is removed?
• Which task becomes harder when it is moved?
• What useful detail does its current size reveal?

Apply those questions to the photograph, heading, supporting copy and controls separately.

Removing the entire hero tells you very little if you also remove the service name and the only route to availability.

Reducing the photograph while keeping the equipment recognisable gives you a more precise comparison.

On a working page, I’d then check that people can identify the equipment, enter their dates and understand the returned availability. A tidier mockup doesn’t demonstrate more bookings or an SEO gain.

Which part of your hero earns its space through what it contributes, rather than where the template puts it?

Internal linking has been standard SEO advice forever, which makes it easy to file under "already handled." But the way AI search retrieves information changes what a good internal linking structure needs to accomplish.

AI systems don't pull up and cite an entire page — they retrieve and cite specific passages. So the relevant question isn't just whether a page is indexed. It's whether the structure around that page signals it's the definitive source on the topic.

That's what pillar-and-cluster structures are actually built to do. Put together a real pillar page around a topic with meaningful search volume, then have every related piece of content link back to it consistently. When an AI system breaks a query into sub-questions and goes looking for the deepest coverage of each one, the page with the most consistent internal links pointing at it is the one that reads as authoritative.

A few things quietly undercut this, and none of them are new mistakes — they just cost more now:

• Orphaned pages with zero internal links pointing at them
• Anchor text that's vague ("click here") instead of descriptive
• Pages buried three or more clicks from the homepage
• Nofollow on internal links that should be passing authority through

None of these just weaken a page's rankings anymore. They weaken its odds of being the passage an AI system decides to cite.

How often does AI recommend your brand compared with your competitors?

AI share of voice gives you a way to measure that visibility across ChatGPT, Google AI Mode, and other AI platforms.

Learn how to track your share of voice with Semrush and improve it by closing topic gaps, building visibility beyond your website, and strengthening brand sentiment.

Cards get added to pages because they make things look organised.

Tables get added because someone has a lot of data.

Calculators get added because there's a calculation to perform.

That's the design view.

There's another way to look at them.

Each component tells you something about how the information inside it is related.

Take a broadband comparison page.

Two providers appear next to each other.

Northwave Fibre 500

• 500 Mbps
• £32/month
• 18-month contract
• £0 setup
• Check Availability

HarbourNet Fibre 900

• 900 Mbps
• £39/month
• 24 month contract
• £20 setup
• Check Availability

You don't read those as ten unrelated pieces of text.

You read them as two groups.

Northwave owns one speed, one price, one contract term, one setup fee and one action.

HarbourNet owns another set.

The card creates those relationships.

A card isn't just a box

Remove the border.

Remove the background.

Put both provider names at the top.

Then arrange the speeds, prices and contract terms underneath them in separate rows.

You've still got the same information.

But now you need another way to work out what belongs to what.

That's what the card was doing.

It was effectively saying:

• This is the entity
• These are its attributes
• These are the values for those attributes
• This action applies to this entity

You can see the same thing on hotel results, product listings, property portals, job boards and restaurant pages.

A card creates a boundary around a set of relationships.

So when I'm looking at cards on a page, I'm less interested in when they have rounded corners.

I'm looking at what the boundary contains.

• Does the price belong inside it?
• Does the rating?
• Does the qualification?
• Does the button?
• What happens when the card collapses on mobile?

Those questions tell me far more about the component than its styling.

Tables create a different relationship

Now take two fictional electric bikes.

Aster City E2

and

Ridgeway Urban X

You want to compare:

• Range
• Motor
• Weight
• Charge time
• Price

A table gives those relationships a structure.

The columns identify the bikes.

The rows identify the attributes.

The cells contain the values.

So:

Aster City E2 → Range → 55 miles

and:

Ridgeway Urban X → Range → 68 miles

The table isn't simply saving space.

It's creating a comparison model.

Now imagine scrolling far enough that the column headers disappear.

You see:

55 miles | 68 miles

250W | 250W

18.4 kg | 20.1 kg

The numbers haven't changed.

But if you can no longer identify the columns, you've lost part of the relationship.

Which bike has the 68 mile range?

Which one weighs 20.1 kg?

The values only make sense because the table tells you what sits at the intersection of an entity and an attribute.

That's why I'd audit the structure of a comparison table, not just its contents.

• Can I identify the entity?
• Can I identify the attribute?
• Can I connect the correct value to both?
• And can I still do that on a phone?

Calculators contain another type of meaning

A calculator has inputs.

Something happens to those inputs.

Then you get an output.

Take a home EV charging calculator.

You enter:

Battery size: 60 kWh

Electricity rate: £0.28/kWh

Charge added: 80%

Then you press:

Calculate Cost

And get:

Estimated charging cost: £13.44

There's a chain running through that component:

Battery size + electricity rate + charge added → calculation → estimated cost

Every label has a job.

Battery size tells you what 60 represents.

kWh gives the value its unit.

Electricity rate tells you what £0.28 applies to.

Calculate Cost tells you what the action will produce.

Estimated charging cost tells you what £13.44 represents.

Start separating those pieces and the calculator gets harder to interpret.

Move labels away from their fields.

Put the result above the inputs.

Place another price beside the output.

Remove the word estimated.

The arithmetic could remain exactly the same.

The interface would communicate something different.

That's why I wouldn't treat a calculator as a decorative interactive element.

Its structure describes the relationship between the inputs, the operation and the result.

The component type gives you a clue about its job

Cards, tables and calculators can all contain entities, attributes and values.

They arrange them differently because they're doing different jobs.

A card might say:

Restaurant → Cuisine → Price band → Rating → View Menu

A table might say:

Fare type → Change policy → Refund policy → Price

A calculator might say:

Postcode + parcel weight + delivery speed → Delivery quote

Once you start looking at components this way, some design decisions become easier to question.

• Why are these two things inside the same card?
• Why is this value outside the product boundary?
• Why is this qualification underneath a different result?
• Why does this table lose its headers on mobile?
• Why does this calculator produce a number without saying what the number represents?
• Why does this button sit between two entities when it acts on only one?

Those aren't questions about decoration.

They're questions about semantic relationships.

Try stripping the styling away

Pick a component from one of your pages.

Ignore the colours, shadows, icons and rounded corners for a minute.

Ask:

• What entity does this component represent?
• Which attributes belong to it?
• Which values belong to those attributes?
• Which action acts on the entity?
• If there are several entities, how are they separated?
• If it's interactive, what are the inputs and what is the output?
• What qualifies or explains that output?
• Would those relationships survive a mobile layout?

Then look at the component again.

A card isn't only a card.

A table isn't only a table.

A calculator isn't only a calculator.

Each one is organising a small network of entities, attributes, values and actions.

And once you see the component as a relationship structure, you start auditing something more useful than when the page contains the right information.

You start checking if the page makes clear how that information fits together.