AMP Landing Page
An AMP landing page is built with Accelerated Mobile Pages, a stripped-down HTML framework that loads near-instantly on mobile, often pre-rendered from a cache.
Key takeaways
- Validation gates AMP: fail it and the page loses cache eligibility entirely, silently.
- Prerendering from the platform cache supplies most of the speed, not the markup rules.
- Inline CSS is size-capped and custom JavaScript is replaced by a fixed component library.
- Branching quiz logic, live scoring and CRM handoff cannot run inside AMP.
- Maintaining an AMP twin creates copy, offer and tracking drift against the canonical page.
In depth
An AMP document must pass a validator before anything else happens. Styles live in a single inline block with a hard size cap, external stylesheets are blocked apart from fonts, custom scripts are replaced by amp-img, amp-form and similar components, and every image declares its width and height so the layout is computed before a byte of media arrives. A valid document may then be served from a search or platform cache on the referrer's own origin, which allows it to be fetched and partially rendered while the user is still on the results page.
Most of the perceived speed comes from that prerender, not from the markup rules alone. Serve the same AMP file from your own domain with no cache in front of it and the gap against a well-built standard page narrows sharply. The gap also closes as teams add back what they stripped: runtime content through amp-list, embedded widgets through amp-iframe, three web font weights, a second measurement endpoint. The structural cost is duplication, since a canonical page and its AMP twin drift apart in copy, offers and tracking.
In practice AMP survives where the cached prerender still applies: editorial and comparison content that earns organic mobile traffic, and ad destinations on platforms that serve the cached copy. Single-step capture works through amp-form, but branching question logic, live scoring and a CRM handoff do not fit inside the component set. The workable pattern is a split funnel. The AMP page carries the promise and the click cheaply, then hands off to a standard page where the scorecard runs its question flow and writes the qualified lead.
The framework has lost much of its original leverage. Search systems no longer require AMP for prominent mobile placements, and Core Web Vitals judge every page on the same field measurements, so a standard page with a small critical path and no render-blocking third parties can match AMP timings without the constraints. AMP also misleads whenever load time is treated as the goal. A document that paints in a fraction of a second but cannot qualify anyone is fast and commercially empty, so the decision belongs downstream.
Example in practice
How to measure it
Run the same content as AMP and as a standard page and compare three inputs. First, largest contentful paint on real mobile field traffic rather than lab runs. Second, the share of landing visitors who reach the next step. Third, qualified leads per thousand sessions. The first tells you whether the constraint bought speed; the other two tell you whether that speed bought anything commercially. A page can win the first and lose both others.
Track the handoff specifically, since that is where a split funnel breaks. Of visitors who land on the AMP page, what share taps through to the page running the quiz, and what share of those finish it. Handoff falling while load times hold steady points at message or layout, not performance. Watch validation errors on a schedule too, because one invalid component removes the document from the cache without any visible warning.
Common mistakes
The usual pattern is to launch a lean AMP page, then quietly rebuild the original. A chat widget arrives through amp-iframe, a second analytics endpoint is added, a hero video and three font weights follow. The validator still passes and the page still caches, but the timing advantage erodes while a second codebase stays alive. Before adding any component, ask whether the canonical page could carry it just as fast, and retire the twin instead of feeding it.
The second failure is attribution. AMP sessions arrive from a cache domain, so identifiers split and the AMP page appears to convert almost nobody while the canonical page appears to convert everybody. Teams then kill a page that was earning clicks or protect one that was not. Configure linking between the cache origin and your own domain before you compare anything, and compare qualified leads produced end to end rather than sessions counted on each hop.
Frequently asked questions
Is AMP still relevant for landing pages?
AMP no longer receives the special search ranking boost it once did, so its main value is now raw mobile speed. Many teams use modern fast frameworks instead and reserve AMP for ad teasers where instant loading matters most.
Can I run a full quiz funnel inside AMP?
Usually not cleanly, because AMP restricts custom JavaScript and many third-party integrations. A common pattern is an AMP teaser that hands off to a standard interactive scorecard page.
What is the main downside of AMP?
You trade flexibility for speed and often maintain a separate page version. Rich interactivity, custom tracking, and many marketing widgets can be difficult or impossible to embed.
Is an AMP landing page still worth building?
Only where the cached prerender still applies, which usually means organic mobile content or ad platforms that serve the cached copy. For a self-hosted campaign page you control, a standard page with a small critical path and no render-blocking third parties reaches similar timings and keeps full scripting. Build AMP for reach you cannot otherwise get, not as a general speed strategy.
Can you run a quiz or multi-step form on AMP?
Not a real one. The amp-form component handles a single submission to an endpoint, but branching logic that changes the next question, live score calculation, conditional result pages and a CRM handoff all need scripting the component set does not expose. The practical answer is to use AMP for the teaser and start the scorecard on a standard page.
Does AMP improve search rankings?
Not directly. Search systems dropped AMP as a requirement for prominent mobile placements and now evaluate any page on the same field measurements for loading, interactivity and layout stability. AMP makes those measurements easy to pass because it forbids the things that usually break them, but the ranking benefit comes from the measurements, not from the framework label.
What breaks when you convert a landing page to AMP?
Anything driven by custom JavaScript: personalisation scripts, most chat and booking widgets, third-party testing tools, dynamic pricing tables, and any multi-step logic. Style rules beyond the inline size cap are dropped, and images without declared dimensions fail validation. Audit the page's third-party inventory first, because that list usually decides whether conversion is even feasible.
How do you track conversions on an AMP page?
Use the amp-analytics component and configure client identifier linking between the cache origin and your own domain, otherwise the cached visit and the follow-on visit look like two unrelated people. Decide in advance which page owns the conversion. Counting a lead on the standard page while spending is attributed to the AMP click is the most common source of contradictory reports.
Should ads point at the AMP page or the canonical page?
Point at whichever version the platform will actually serve from its cache, because the prerender is the whole advantage. If the platform links out to your own origin, the AMP file gains you little and costs you scripting. Where the cache does apply, send traffic to AMP for the first click and hand off to the canonical page for qualification.