CTA Design Tips to Improve Website Conversions
Make calls to action clear, accessible, and easy to find. Learn how to choose button labels, placement, semantics, and tests that fit your page goal.
A call to action (CTA) helps a visitor take the next step your page is meant to support. Make that step clear in the label, use the control that matches its behavior, and give the main action enough visual prominence to be found without surrounding it with competing buttons. There is no button color, shape, placement, or wording that guarantees higher conversions on every site; treat design choices as hypotheses to test against your own goal.
This guide covers how to choose a CTA, write its label, place and style it, preserve accessible behavior, measure outcomes, and investigate common implementation problems.
1. Define the action before designing the CTA
Start with the visitor’s task and the page’s purpose. Ask: what should someone be able to do next, and what will happen when they activate the control? A product page might invite a purchase, a pricing page might offer an estimate, and a guide might point to a related resource. The label, destination, and resulting action should agree.
Distinguish the page’s main goal from functional actions that complete an interaction. For example, “Get an estimate” can be the page’s main CTA, while “Submit” sends the form and “Save” stores an edit. These actions serve different roles and can have different visual priority. The European Commission component library reserves CTA treatment for the page’s main goal and advises against more than one CTA per page except when there are multiple genuine main actions or the action is repeated. European Commission button usage guidance.
Make the destination or result predictable
- For a link, the destination should match the words. “Download the guide” should download or lead directly to the guide.
- For a button, activating it should perform the promised action, such as submitting a form or opening a dialog.
- If there is a material condition, explain it near the CTA. Do not imply that an action is immediate or unconditional if it is not.
- For a choice with consequences, label both choices in terms visitors can understand. Do not make a destructive or costly option look like the routine next step.
2. Write a specific, action-oriented label
Prefer a concise verb, followed by a useful object or outcome where needed. “Get estimate” is more informative than “Continue” when a visitor is requesting a quote. “Download the guide” makes the destination clearer than “Click here.” The Government of Canada design system recommends short, specific labels with a verb or verb-plus-noun; the NCI Design System likewise recommends starting with an action verb and explaining what will happen. Government of Canada button guidance and NCI button guidance.
| Vague or context-dependent | More specific when accurate |
|---|---|
| Continue | Continue to payment |
| Submit | Send application |
| Learn more | View pricing details |
| Get started | Create a free account |
| Click here | Download the guide |
These are examples, not universal replacements: use wording that truthfully describes what happens on your page. “Submit” can be a reasonable label when the surrounding form makes the task unambiguous. Avoid arbitrary character-count rules or manufactured urgency. If the same label appears more than once, add distinct surrounding context so people can tell the links apart, including when navigating by assistive technology.
3. Make the main CTA easy to find
Use a recognizable, consistent treatment for the main action and ensure its boundary is visible against the page surface. Reserve the strongest emphasis for actions that matter most; use a quieter treatment for secondary actions and links. Too many equally prominent buttons make it harder to tell which action is primary.
Put the action where it makes sense in the visitor’s path, near the information needed to decide. A long page may need the same action repeated after meaningful sections, but repetition should support the task rather than turn every section into a row of competing prompts. A predictable placement and visible button boundary are recommendations in the Government of Canada guidance, not proof that a particular color, size, shape, or above-the-fold position always wins.
Consider sticky CTAs as a testable option
A fixed or sticky CTA can keep an action available while someone scrolls, but it can also cover content, consume limited mobile space, or distract from reading. Treat sticky placement as a hypothesis: verify that it does not obstruct content or controls at supported viewport sizes, and compare task outcomes with a non-sticky version. Optimizely’s conversion toolkit suggests testing sticky CTA buttons; that suggestion does not establish a universal benefit. Optimizely conversion best practices toolkit.
4. Use the right HTML element and accessible name
Use an anchor for navigation and a button for an action or state change. Styling a link to look like a button does not change its semantic role: it should still navigate. A button should not pretend to be a link if it changes nothing or fails to perform the expected action.
<!-- Navigation: use a link -->
<a class="button button--primary" href="/pricing/">View pricing</a>
<!-- Action: use a button -->
<button class="button button--primary" type="submit">Send application</button>
<!-- Icon-only action: provide an accessible name -->
<button type="button" aria-label="Close dialog">
<svg aria-hidden="true" viewBox="0 0 16 16">...</svg>
</button>
For a form, give each input a programmatically determined name. A nearby named button can sometimes help explain an input’s purpose, but it does not remove the need to label the input. W3C WAI Technique G167 describes an adjacent button as one possible sufficient technique for a relevant criterion, not a required pattern. For additional checks, the UK DWP accessibility manual covers clear purpose, consistency, text alternatives, and the distinction between links and buttons. W3C WAI Technique G167 and DWP links and buttons guidance.
- Make interactive controls operable with a keyboard and show a visible focus indicator.
- Give icon-only controls a text alternative or another programmatic accessible name.
- Keep repeated controls named consistently, and give repeated links enough context to distinguish their destinations.
- Do not rely on color alone to communicate the primary action or its state.
- Check that a disabled or loading state is conveyed and that the control cannot be accidentally activated twice when an action is in progress.
5. Test a meaningful outcome, not just a button click
Before changing a CTA, define the outcome that matters for the page: a completed purchase, qualified lead, form completion, download, or another completed task. Click-through rate can help diagnose whether a prompt is noticed, but a click is not necessarily a successful result. Where possible, inspect what happens after the click and whether the resulting users or leads meet the intended goal.
- Write down the hypothesis, such as “Naming the destination will help visitors choose the pricing link.”
- Change one meaningful aspect at a time when the traffic and setup allow a useful comparison.
- Choose the primary outcome before reading results; track relevant downstream outcomes as well.
- Check that both variants work, render correctly, and are accessible on the devices you support.
- Interpret results in context. A higher click rate with fewer completed tasks or lower lead quality may not be an improvement.
A NICE Design System article reports an organization-specific April 2021 test with button clicks as the primary goal: flat buttons recorded 6.24% over 152,123 experiment sessions, solid shadow 6.45% over 152,301 sessions, and blur shadow 6.57% over 153,451 sessions. NICE said it considered other conversions and user attributes before choosing the blur-shadow variant. This is a historical result from one organization’s test, not a forecast or a general rule that blur shadows improve conversion elsewhere. NICE Design System button guidance.
6. Capture comparable screenshots when reviewing CTA changes
Visual review can help a team spot whether a CTA is visible, whether secondary actions compete with it, and whether a responsive layout covers content. Keep comparisons consistent: use the same URL state, viewport, device scale, scroll position, and page readiness conditions. A screenshot shows appearance at a moment in time; it does not establish accessibility or prove that a design converts better.
For manual review, open the page at the viewport sizes your audience uses, load the same content state, and capture the relevant section or full page. Check the result on desktop and mobile, including sticky behavior and dialogs. For repeatable reviews across variants, automate the capture with a browser or screenshot API and keep the capture settings identical.
Do-it-yourself browser capture with Playwright
This runnable Node.js example takes full-page screenshots of a page at two viewport widths. It waits for the page’s load event, then captures PNG files. Install Playwright and its browser once before running:
npm install playwright
npx playwright install chromium
// save as capture-cta.mjs
import { chromium } from 'playwright';
const target = process.argv[2] ?? 'https://example.com';
const browser = await chromium.launch({ headless: true });
try {
for (const width of [1440, 390]) {
const page = await browser.newPage({
viewport: { width, height: 900 },
deviceScaleFactor: 1,
});
await page.goto(target, { waitUntil: 'load', timeout: 45_000 });
await page.screenshot({ path: `cta-${width}.png`, fullPage: true });
await page.close();
}
} finally {
await browser.close();
}
Run it with node capture-cta.mjs https://your-site.example/landing-page. Replace the example URL with a page you are authorized to inspect. If the page relies on client-side rendering, wait for a page-specific selector that signals the content is ready. Avoid blindly waiting for all network activity to stop: analytics, chat, and streaming requests can keep a page busy indefinitely.
Capture with cURL
ScreenshotNeo accepts a URL in one GET request and returns an image or PDF. This example saves a WebP screenshot. See the ScreenshotNeo API documentation for parameters and response details.
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://stripe.com \
-o shot.webp
Capture with Python
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)
Capture with Node.js
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);
In Node.js environments without Bun, write the response bytes with the runtime’s filesystem API:
import { writeFile } from 'node:fs/promises';
const bytes = new Uint8Array(await res.arrayBuffer());
await writeFile('shot.webp', bytes);
7. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. Its one-call API can capture a page as PNG, JPEG, WebP, or PDF. For CTA review, you can use a chosen viewport, device preset, full-page capture, or element selector, and keep capture settings consistent across page variants.
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://stripe.com \
-o shot.webp
Cookie and consent banners are accepted before capture, and more than 60 known consent platforms, newsletter popups, and chat widgets can be removed; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers identify the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots, and every feature is available on every plan. See the API documentation for setup and options.
Sign up for 1,000 free screenshots a month with no card.
8. Performance, reliability, and cost considerations
Keep captures useful and repeatable
- Readiness: Choose a meaningful readiness condition, such as a selector or a short delay for a known animation. Network-idle waits can be unreliable on pages with persistent requests.
- Viewport: Use the same width, height, and scale for comparisons. A layout change can move the CTA or alter sticky behavior.
- Dynamic content: Consent state, personalization, rotating promotions, and timestamps can differ between captures. Control what you can and note what remains variable.
- Retries: Retry transient navigation or service errors with a limit and backoff. Do not retry a deterministic invalid URL or authentication failure unchanged.
- Batching: If capturing many pages, limit concurrency to avoid overloading your own browser machine or target site. ScreenshotNeo supports bulk capture of up to 100 URLs per call.
- Cache: A cached image can reduce repeat work, but ensure the cache lifetime is appropriate when comparing a page that may have changed.
Budget and data handling
For self-hosted browser automation, account for browser execution time, memory, browser installation and maintenance, and the infrastructure needed to store and review images. For an API, estimate the number of successful captures and compare it with the plan allowance. ScreenshotNeo lists 1,000 free shots monthly, then Starter at $5 for 3,000, Growth at $15 for 15,000, Pro at $39 for 60,000, Scale at $99 for 250,000, and Business at $249 for 1,000,000; yearly billing gives two months free. Only clean shots are billed under the stated product rules, and cache hits are free. Keep API keys out of public client-side code and avoid including secrets in URLs that may be logged.
9. Troubleshooting CTA reviews and screenshots
| Symptom | Likely cause | Fix |
|---|---|---|
| The CTA is hard to identify | Several controls have equal visual weight, or the boundary blends into the surface. | Give the page’s main action a consistent, visible treatment and reduce emphasis on secondary actions. |
| Visitors click but do not complete the task | The label, destination, or post-click flow does not match expectations; clicks may be a poor success metric. | Check the full journey and track the intended completion outcome, not only activation. |
| A link or button behaves unexpectedly with keyboard or assistive technology | The element’s semantics do not match its behavior, the accessible name is missing, or focus is not visible. | Use an anchor for navigation and a button for actions; provide a programmatic name and visible keyboard focus. |
| Playwright times out at navigation | The page is slow, keeps network connections open, or the chosen readiness event never occurs. | Use an appropriate timeout and wait for a page-specific selector or a less strict load condition; inspect whether the URL is reachable. |
| The screenshot is blank or missing the CTA | Capture ran before client rendering completed, the wrong URL/state loaded, or the CTA is below the captured area. | Wait for a selector that identifies the CTA, check the final page URL, and use full-page capture or scroll to the target. |
| A sticky CTA covers mobile content | The fixed element consumes too much of the small viewport or ignores safe-area/layout constraints. | Test supported mobile sizes, reserve space where needed, and compare against a non-sticky layout. |
| The API returns an error or no usable image | Invalid credentials or URL, an unsupported destination, page failure, or an incomplete response. | Check the HTTP status and response headers, confirm the encoded URL and API key, and consult the API documentation. Do not treat a page-verdict response as a normal screenshot without checking its headers. |
10. Frequently asked questions
Should every page have exactly one CTA?
No. A page should make its main goal clear, but multiple genuine main actions or repeated actions along a long page may be appropriate. Keep their roles understandable and avoid making every option equally prominent.
Is “Submit” a bad button label?
No. It can be clear when the form context makes the result obvious. A more specific verb-plus-object label can reduce ambiguity when the form’s purpose is not already apparent.
Does a brighter color increase conversions?
There is no universal winning color. Check contrast and visibility, then test plausible alternatives against a defined outcome on your own site.
Should I put the CTA above the fold?
Place an action where it is findable when the visitor has enough context to take it. The right location depends on the page and user task; a fixed position is a testable option, not a rule.
Can a CTA be a text link?
Yes. Use a link when the next step is navigation, and make its destination clear. A CTA does not have to be a filled button.


