PrestaShop homepage layout and back-to-top controls

What we would do

We would keep the working theme and native blocks, give the first screen a clear destination, then remove or reorder blocks that compete with it. The route depends on your existing theme, builder, modules, catalogue data, integrations, languages and markets, and who will maintain campaigns. Check what your current tools support before adding another module or commissioning a redesign.

Make structural, theme or code changes on a staging copy with the same module stack and representative products, isolated from live emails, orders and external exports. Rehearse the journey from the homepage to purchase, record the old hook order and settings, and keep copies of changed assets. Agree a publication window and a reversible switch with the person responsible for the shop. Restore the changed layout or configuration if needed, without overwriting new live orders with a staging database.

For a prioritised diagnosis, the PrestaShop UX & Conversion Design Audit supplies a repair plan; for configuration of a theme you already own, the PrestaShop Theme Installation & Setup Service covers the agreed setup rather than a new design.

Which layout should you start with?

Find the modules and hooks that build your homepage

The native index controller renders homepage content through theme templates and hooks. In standard layouts, displayHome supplies the main module stack; header and footer hooks surround it. A third-party theme or page builder can change this arrangement.

1. Identify the active theme and any homepage builder.
2. Open Design > Positions, find displayHome and record its modules and order.
3. Open each module's configuration for its own text, media or product selection. Record the source category or feed and who maintains it.
4. Reorder or unhook blocks where the theme supports it, then inspect desktop and mobile output.

Classic installations commonly use ps_imageslider, ps_customtext, ps_featuredproducts and ps_banner. The installed modules and their order in displayHome depend on the theme and distribution; record your PrestaShop and theme versions alongside the block map. Hummingbird became the fresh-install default in PrestaShop 9.1; upgraded shops can retain an earlier theme.

If a saved change does not appear, confirm the selected shop and language, the module's hook placement and any builder-controlled layout, then clear the relevant cache through the supported controls. Compare the rendered page while logged out; a back-office preview alone does not prove what customers receive.

Hummingbird's default configuration hooks the slider, custom text, featured products, banner, new products and best sellers into displayHome. Check the actual positions in your shop before editing its homepage.

Give the first screen a clear job

Explain what you sell, why the offer is relevant and where the visitor should go next. “Walk-in shower systems” or “Handmade leather bags from Florence” is clearer than “Quality products for modern living”. Check the rendered homepage for a missing or empty H1 and set a meaningful, visible H1 through the theme's homepage template or a supported content block. Use a descriptive action such as “Shop walk-in showers”.

The first screen varies by viewport, zoom, browser controls, notices and header size. Test actual screens rather than assuming a fixed fold height. A brief comprehension exercise with someone unfamiliar with the store can reveal unclear wording, but a three-second test is not a conversion benchmark.

A static hero can keep one message visible and reduce competing media. A carousel may suit several campaigns, but users need clear controls, readable content and time to act. The relevant auto-forwarding usability research concerns specific usability problems.

Compare a single slide or static hero with your existing slider. Check what images and scripts actually download and identify the LCP resource. Keep the initial hero eager, reserve its space and avoid unreadable text baked into an image.

Banner Revolution supports banner media, overlays, calls to action, scheduling and mobile media/layout variants; see Banner Revolution help.

Curate categories and products as routes into the catalogue

Choose category entry points from your range and customer tasks. Use clear labels such as “Women's Boots” rather than internal seasonal codes. A small visual grid can be a useful starting point; four to eight categories is an editorial option, not an established optimum or a guarantee that images get more clicks.

Keep the persistent menu and search usable. The homepage category grid is a shortcut rather than a substitute for navigation. See the navigation guide for category trees, headings, menu behaviour, filters and listings.

The native Featured products block draws from a configured category, commonly Home, and has a configurable display count. Assigning a product to that source category is different from setting a universal “featured” product flag. Open Modules > Module Manager and configure ps_featuredproducts to set its source category and display count, then check its sorting and theme output.

Use a focused selection of products appropriate to the page: useful best sellers, new items or a representative spread of prices. You can try eight to twelve products as an initial layout, then adjust from the results. Show truthful availability and a sensible next action for items needing combinations. Clearance products can be appropriate when clearance is the actual campaign.

If a manually selected row becomes stale and you need an automated source, Showcase Revolution offers automated selections, with trending products based on your shop's views and valid sales. Check the chosen source against actual catalogue data and the theme's product cards before replacing a working native block.

Use filters for narrowing large ranges and search for known-item tasks. A longer homepage containing the full catalogue does not replace those tools.

Work through a shower shop's homepage

Suppose your slider promotes trays, drains and screens on separate slides, while the menu uses supplier collection codes. Keep the hero focused on walk-in shower systems, point its action to a suitable existing category, and give trays, drains and screens their own clearly labelled routes below it. Place a specific campaign further down so it does not replace the explanation of your range.

On staging, ask someone unfamiliar with the catalogue to find a tray that fits their space. Follow the route from the homepage card through the listing and filters to a product with size choices. Confirm that the card opens the intended category in each language and that a product needing a combination leads to a usable selection rather than a failing quick-add action. If the visitor reaches the wrong range, correct the label or destination before adding more homepage blocks.

Use accurate claims, useful copy and the correct SEO fields

Show review ratings, order counts, press references, payment marks and guarantees only when you can substantiate them and have permission to use the assets. A claim such as “50,000 orders” needs records. A security badge is not proof that a checkout is safe.

Explain relevant differentiators: an actual free-shipping threshold, warranty, dispatch cutoff or service. Link fuller conditions where needed. Add a short brand introduction and buying guidance when they help visitors choose.

For native homepage metadata, open Shop Parameters > Traffic & SEO and edit the index page entry. Do not edit pagenotfound, which describes the error page. Check the rendered title and meta description after saving. They are separate from the visible H1, which comes from the theme or content.

HTML Blocks can place custom content through hooks, template integration or selectors; see HTML Blocks help. Maintain any device-specific CSS in your theme or extension.

A latest-articles block needs an installed content system or module; native CMS pages are not a complete blogging workflow. Keep useful information available in mobile HTML, even when you organise it in accordions. Avoid hiding essential content merely to imitate a leaner page.

Test the mobile layout and its cost

Check your own device-category sessions, onward actions and purchases. Do not assume mobile is the majority of every store's traffic. Hummingbird and Classic are responsive, but modules, long content and custom CSS can still overflow.

• Use a readable mobile hero crop or media variant.
• Make category and product cards large enough to recognise and operate.
• Compare a grid with an accessible scrolling row rather than declaring one universally better.
• Keep navigation, search and cart reachable.
• Consolidate repeated reassurance and remove unnecessary third-party embeds.
• Make dialogues dismissible and avoid covering the first useful content immediately on arrival.

Autoplay video, sliders and social feeds can add requests and processing. Inspect the waterfall before deciding what to remove. Keep image dimensions and responsive files appropriate; use the image guide for sizing and lazy loading.

Record homepage-to-category/product clicks, successful searches, exits and eventual purchases. Compare similar acquisition sources and customer groups. A long visit can indicate interest or confusion, and homepage entrants need not convert like visitors arriving directly at a product.

Decide whether a back-to-top control is useful

Scroll long homepage, category, product and content pages on desktop and phone. First check whether the theme, builder or a module already provides a working control. Look for elements such as back-to-top or scroll-to-top and trace their source. Some themes provide an option; do not assume all paid themes do.

Classic-specific observations do not describe every new PrestaShop 9 store. Check the installed theme before adding a second button. If an existing control is broken, inspect its setting, console errors and stacking behaviour before replacing it.

Editing the active parent theme's footer.tpl, theme.js, custom.js or custom.css can be overwritten. A file called “custom” is not automatically protected. Confirm the theme loads your external assets. Footer injection works only when the module supports a hook and the theme renders it, for example displayFooter or displayBeforeBodyClosingTag.

If no suitable control exists and staff need settings they can manage, Back to Top Button provides trigger distance, side, size, spacing and separate desktop and phone visibility. Disable any competing control and test the result with your actual floating widgets.

A sticky header may already make search and cart reachable. Test whether a top control helps customers navigate your longer pages.

Implement and test an accessible scroll control

Use a real button with an accessible name. Keep a visible focus indicator, adequate contrast and a comfortable touch target. Place the markup through your chosen module or child theme, and place CSS and JavaScript in external assets. The following is example source code, not executable page content.

<button type="button" id="back-to-top" aria-label="Back to top" hidden>↑</button>

#back-to-top {
  position: fixed;
  right: 1rem;
  bottom: 1rem;
  width: 48px;
  height: 48px;
}
#back-to-top:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

const topButton = document.getElementById('back-to-top');
if (topButton) {
  const updateTopButton = () => {
    const shouldHide = window.scrollY <= window.innerHeight;
    if (shouldHide && document.activeElement === topButton) return;
    topButton.hidden = shouldHide;
  };
  window.addEventListener('scroll', updateTopButton, { passive: true });
  updateTopButton();
  topButton.addEventListener('click', () => {
    const reduce = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
    window.scrollTo({ top: 0, behavior: reduce ? 'instant' : 'smooth' });
  });
}

Load this after the markup or through your theme's supported initialisation. The threshold of one viewport is a design choice; test it. This small scroll callback still runs on the main thread. A passive listener does not move it elsewhere, and requestAnimationFrame coordinates rendering rather than guaranteeing a lower event frequency. Use measured throttling if actual handler cost requires it. See MDN's scroll-event guidance.

Choose offsets and stacking against your real page, not an arbitrary huge z-index. Test with consent notices, chat, sticky add-to-cart, mobile submit bars, and browser safe areas. A visible control can still be unclickable beneath an overlay.

1. Check no duplicate button appears.
2. Use Tab and Enter/Space to operate it and confirm focus stays visible.
3. Test reduced-motion settings and a page restored at a scrolled position.
4. Check product purchase controls remain usable when all floating widgets are present.
5. Test long categories, reviews, CMS pages and the homepage on supported phones.
6. If useful, record a consent-appropriate click event and inspect usage by page. Clicks do not by themselves prove higher conversion.

Publish the layout and hand it over

1. Approve the staging version with the actual content owner. Check campaign links, translated labels, offer conditions and product availability, including the state after a scheduled offer ends.
2. Follow menu, search, category and product routes as a logged-out visitor on your supported phones and desktop browsers. Add a product with options and continue through cart and checkout entry; a homepage change must not break shared controls.
3. Publish the agreed assets and configuration without replacing live customer or order data. Refresh the relevant caches and check the public page, including consent accepted and rejected where external content depends on it.
4. Compare the homepage measurements described above with a comparable period and traffic mix. If onward actions fall, inspect broken destinations, unavailable products and loading problems before attributing the change to the design.
5. Hand over the block map, settings, asset locations and rollback steps. Name the person who updates each campaign and checks the layout after theme or module updates.

What to ask your developer or agency

• Which blocks come from the theme, builder or modules, and which settings can our staff edit?
• Which requirement cannot our existing tools meet, and what evidence justifies the proposed addition?
• Where do custom assets live, and how will you review them when the parent theme changes?
• Which devices, languages and purchase routes passed testing, and who can restore the previous layout?

Questions owners ask

Will hiding a homepage product block remove its products?

Unhooking a display block removes that placement, not the catalogue records. Avoid deleting a source category or changing product assignments merely to hide a row. Also check other placements before uninstalling a module that supplies more than the homepage.

Does removing a promotional banner end the offer?

No. Banner visibility and the product price or cart rule are separate controls. Match their intended start and end conditions, then check the offer and its destination after the banner disappears.

Can each shop in multistore have a different homepage?

Check whether the theme, builder and relevant modules store content per shop. Select the intended shop context before editing, and inspect the other shops afterwards. Shared configuration can change more storefronts than the one you previewed.

Do I need jQuery for the example button?

No. The example uses browser APIs and does not require that library. If a builder renders the control again, make sure its initialisation does not attach duplicate event handlers.

Why does the example not scroll an independent panel?

It watches and scrolls the window. A modal or builder panel with its own scrolling area needs logic targeting that element instead. Ask your developer to identify the actual scroller and test it separately from the document.