Why This Kind of Page Is Harder to Get Right Than It Looks
There is a specific design challenge that comes up more often than people expect: a presenter needs a webpage that hosts a video — or a playlist of videos — and a QR code that an audience can scan during or after a presentation to reach that content instantly. The concept sounds simple. The execution rarely is.
Done badly, this kind of page creates friction at exactly the wrong moment. A QR code that lands on a cluttered, slow-loading WordPress page kills momentum. A video that does not autoplay on mobile, or a layout that breaks on a projector screen, undermines the entire reason the presenter built the page in the first place. The stakes are higher than they appear because the page functions as a live extension of the presentation itself — it is the bridge between a room full of people and the content they are meant to engage with.
Done well, the page feels invisible. The audience scans, the video loads, and nothing gets in the way of the message. That outcome takes deliberate UI/UX decisions at every stage, from WordPress template selection through QR code generation and mobile layout testing.
What the Work Actually Requires
Building this kind of page properly is not a theme-swap exercise. There are four things that separate a well-executed build from a rushed one.
First, the information architecture has to be brutally minimal. This page exists to deliver one action — watch the video. Every element that does not serve that action is a liability. Navigation menus, sidebars, pop-ups, and cookie banners all compete with the primary goal and need to be suppressed or removed for this specific page template.
Second, the QR code itself needs to be generated against a stable, canonical URL. If the WordPress permalink structure changes after the QR code is printed or embedded in slides, the code becomes a dead link. Getting the URL architecture locked before generating the code is non-negotiable.
Third, the video hosting decision matters more than most people realize. Self-hosting video on WordPress causes page weight and buffering problems that destroy the experience. The right approach routes video through an embed — YouTube, Vimeo, or Wistia — so the page stays light and playback is handled by infrastructure built for it.
Fourth, the design needs to be tested at the actual display sizes the audience will use: a smartphone held at arm's length after scanning a QR code projected at 10 feet. That is a very specific use case, and designing for a desktop viewport alone will not catch the failures that matter.
The Right Approach to Structure, Design, and QR Integration
Setting Up the WordPress Page Template
The foundation is a full-width, blank-canvas page template with no header, no footer navigation, and no sidebar. In most block-based WordPress themes — Kadence, GeneratePress, Astra — this is achievable through a per-page layout override setting in the page editor. The goal is a single-column layout with a maximum content width of 800px centered on the viewport. Anything wider than 800px starts to feel like a desktop document rather than a mobile-first landing page.
Typography should use a clear hierarchy: a headline at 36px or equivalent, a supporting subhead at 22px, and body copy at 16px minimum. These sizes hold legibility on small screens without requiring the reader to zoom. The background should be a single solid color — ideally the presenter's brand primary — so the page feels intentional rather than default.
Embedding Video the Right Way
The video embed goes above the fold. On a standard smartphone viewport of 390px wide, the embed should render at 100% width with a 16:9 aspect ratio preserved. In Gutenberg, this means using the Video or Embed block with the aspect ratio setting locked. For custom page builders like Elementor or Bricks, the equivalent setting is a padding-top percentage of 56.25% on the wrapper div, which enforces the 16:9 ratio responsively without hardcoding pixel heights.
For a playlist scenario — say, three training videos from a single presentation — the right structure is a stacked layout: embed one, brief 14px descriptor text beneath it, then the next embed, and so on. Avoid tabbed interfaces or carousels on this type of page. They add interaction complexity that slows the audience down. Linear scrolling is faster to navigate on a phone after scanning a QR code.
If Wistia is the hosting platform, the turnstile gate feature should be disabled for this use case. Requiring an email to watch a video the presenter just told the audience to scan and watch is a conversion-killing contradiction.
QR Code Generation and URL Architecture
The QR code should be generated after the WordPress page is published and the permalink is confirmed. A URL structure like yourdomain.com/presentation/[event-name] is cleaner and more stable than the WordPress default ?p=123 format. Setting pretty permalinks to Post Name in WordPress Settings > Permalinks resolves this before any codes are generated.
For the QR code itself, tools like QR Code Generator (qr-code-generator.com) or Canva's built-in QR feature produce high-resolution SVG or PNG exports. The code should be exported at minimum 1000x1000px for print use and 400x400px for digital slides. Error correction should be set to level H (30% restoration capacity) when the QR code will include a logo overlay — this accounts for the portion of the code obscured by the logo without breaking scannability.
A good rule of thumb: test the printed or projected QR code at the farthest seat distance expected in the room. A code that scans at 6 feet on a phone but fails at 20 feet from a projector is not ready.
Figma Prototyping Before the Build
The right workflow starts in Figma before touching WordPress. A single mobile artboard at 390x844px (iPhone 14 viewport) lets the designer validate the layout, type sizes, button placement, and video aspect ratio before any code is written or blocks are placed. The Figma file should have three frames: mobile, tablet at 768px, and desktop at 1280px. This prototyping step catches problems — like a CTA button sitting behind the mobile keyboard, or a video embed that clips on a 768px iPad — that are expensive to fix mid-build.
What Tends to Go Wrong With These Pages
The most common failure is skipping the permalink lock-in step. A QR code printed in a slide deck or on a handout is permanent. If the WordPress page URL changes — because of a site migration, a permalink structure change, or a page duplication that creates a slug conflict — every printed code becomes useless. This single oversight has wrecked otherwise solid projects.
Another recurring problem is building the page at desktop scale and assuming it will look fine on mobile. A video embed that renders beautifully at 1440px can collapse into a 240px-tall thumbnail on a 390px screen if the aspect ratio is not constrained responsively. The audience scanning a QR code is almost always on a phone, never on a laptop.
Page speed is underestimated consistently. A WordPress page with an unoptimized hero image, three tracking scripts, and a chat widget can take 6-8 seconds to load on a mobile connection. For a page being accessed live during or immediately after a presentation, that delay is enough to lose the audience entirely. Compressing images to under 150kb, removing non-essential plugins from the template, and enabling caching through a tool like WP Rocket or LiteSpeed Cache are baseline requirements, not nice-to-haves.
Finally, QR code contrast is often an afterthought. A dark-on-dark code embedded in a branded slide with a navy background will fail to scan. The minimum contrast ratio for reliable QR code scanning is the same as WCAG text contrast — at least 4.5:1 between the code foreground and background. Testing with multiple scanner apps (native camera, Google Lens, a third-party reader) before the presentation is the only way to confirm this.
What to Take Away From This
The most important insight here is that this page type has a single job: get a scanning audience to a video with zero friction. Every design decision — template choice, video hosting, URL structure, QR generation settings, mobile layout — should be evaluated against that one criterion. Complexity is the enemy.
If you have the time and the tooling to work through the Figma prototype, WordPress build, and QR testing cycle yourself, the process above gives you a reliable path. If you would rather hand this to a team that does this kind of work every day, check out how we rebuilt a slider with SwiperJS for complex interactive experiences.