LPagery vs Magic Page Plugin

LPagery reads a CSV or XLSX file in your browser, shows the columns before anything is saved, and treats every column as a placeholder. A Google Sheet works by link, and a Radius source fetches cities around a location. Any row becomes a page, whatever the row describes.

Magic Page's spreadsheet import takes XLSX, XLS and CSV on the server, with eleven fixed columns in a fixed order: term id, location, latitude, longitude, zip, region, county, country, major city flag, slug and population. Columns from the twelfth onward become custom fields. A row is a place, so the data model fits location pages and little else. Magic Page's main data source is its own location databases for 19 countries, downloaded from the vendor. Which countries a licence unlocks, and how current the data is, was not verified in this review. No Google Sheets input was found in 7.2.

LPagery syncs a Google Sheet on a schedule, hourly by default and up to weekly. Each run downloads the sheet, creates pages for new rows, updates pages whose row changed, skips rows that did not change, and deletes pages for removed rows when you turn that option on. A failed row is retried and a failed download marks the set with the error.

No Google Sheets integration was found in Magic Page 7.2. The nearest thing is the vendor's update channel for its own location databases: a weekly check tells you when a region has a newer version, and you run the update by hand. It covers the vendor's location data and nothing you wrote yourself.

In LPagery the template is any page, post or custom post type you already have. You add placeholders to it and pick it in the dashboard. Every custom field of that page is copied with placeholders replaced, so builders that store their layout in post meta work through that path, and eleven builders have their own adapter on top. Each page set has its own template, and a set can be pointed at a different one later.

Magic Page has one master page per site. It registers its own post type, blocks a second post as soon as one exists, and the renderer uses the newest one. The master page is edited in the Classic or Gutenberg editor. Elementor is the only builder with a compatibility filter, and Thrive Architect gets one filter for its shortcodes. Divi, Bricks, Oxygen, WPBakery, Beaver Builder, Brizy, Breakdance and SeedProd are not referenced in 7.2, and custom post types as templates were not found either.

LPagery writes real WordPress pages by default, which it calls Classic Mode. Live Mode is the alternative: each page is a small stub and the content is rendered from the template when someone opens it, so a template change shows on every live page as soon as you save. You can switch a page or a whole set between the two modes. Classic pages keep their content when the plugin is deactivated; live pages need converting to Classic first.

Magic Page is virtual by default. Nothing is written to the posts table: one master post is served under every location URL and the location's data is substituted into it on each request. A location is stored as a taxonomy term with one meta row per column. Editing the master page changes every URL on the next request, which is the plugin's structural advantage. Export to Static Pages is the opt-in physical model: it writes one real post per location, with a drip schedule that spreads the publish dates over days.

Two things follow from the virtual model. WordPress search does not find the location pages, because only the master post exists. And every page request runs a distance query over the whole location table, so the cost of a request grows with the number of locations; the numbers are under Scale and limits.

LPagery puts the rows in a queue on your server. A worker drains the queue and each page is generated in its own request, so the PHP time limit applies to one page and never to the whole run. You can close the tab, come back later and see the progress under Manage. Failed rows are retried with a pause between attempts, and a run with no progress for ten minutes is shown as stalled so you know WP-Cron is not running.

Magic Page has no queue and no server-side job runner. Every long operation (the database install, the spreadsheet import, the static export and the unused-location cleanup) is a loop of admin requests driven by your browser tab. Each request raises its own time limit to 60 seconds and processes one batch. Closing the tab ends the run. The static export and the database install keep their position on the server, so you can resume them from the same screen. The spreadsheet import keeps its position only in the browser, so a closed tab starts over and imports rows already written a second time.

Our 300-row CSV took 61.5 seconds through Magic Page's importer in two batches, because the importer re-opens and re-parses the whole spreadsheet on every batch.

When you upload a changed file, LPagery lets you create, ignore or update existing pages. A page is updated only when its row or its settings changed. If someone edited a generated page by hand, LPagery notices that from the save and leaves the page alone unless you choose to overwrite manual changes. Removed rows can delete their pages during a sync.

Magic Page updates locations by re-importing the spreadsheet. A row with a term id updates that location and overwrites its name, slug and every field; a row without one creates a new location. Rows missing from the sheet are left alone, and removal is a separate tool, Delete Unused Locations, which hard-deletes every location outside the master page's radius in batches of 20. Manual-edit detection was not found in 7.2: a location edited by hand is overwritten by the next import, and exported static pages are updated in place, so hand edits to them are lost. Template changes work the other way round: because pages are virtual, a master page edit reaches every URL with no run at all.

Neither paid plan caps the number of pages. LPagery's worker takes 1,000 rows per tick by default and splits a large upload into parts so a small upload limit on the host does not block it. Magic Page imports 100 to 400 rows per request and installs vendor data 50 rows at a time. Two ceilings are specific to Magic Page. A build can hub around at most eight radius centres at a time; further locations have to be selected one by one. And the cost of a page request grows with the location table, because every request counts distances over all locations: in our lab, 25 page requests took 4.2 seconds warm at 309 locations and 10 seconds warm at 5,010, where one request peaked at 56 MB of PHP memory. An LPagery live page costs one existence check plus one indexed lookup per post, whatever the size of the set.

LPagery replaces placeholders in the title, slug, excerpt, content and every custom field, so the fields of Yoast SEO, Rank Math and SEOPress are filled from the template through that one path, and All in One SEO gets its own handler because it stores data in its own table. Image columns get a filename and alt text per page. LPagery emits no canonical tag and no sitemap of its own: it leaves both to your SEO plugin, and the pages are normal posts that show up in the core and SEO plugin sitemaps.

Magic Page is stronger on local SEO output. It emits LocalBusiness JSON-LD per location with address, coordinates, opening hours and social links, plus six geo meta tags. Title, description and keywords run through substitution, but there is no slug pattern: the URL is one global prefix plus the location slug. Yoast SEO and All in One SEO are integrated; Rank Math, SEOPress, The SEO Framework and Slim SEO were not found in 7.2. One image per master page serves as the SEO image, and per-location image columns were not found. Two behaviours reach the whole site. The plugin removes WordPress's core canonical tag on every front-end request and emits its own only when the master page opts in, which is off by default. And on the first admin page load it sets the permalink structure to /%postname%/ without asking. Its own sitemap is off by default; in our lab one location with a space in its slug made that sitemap return an error for every visitor until the location was deleted.

Magic Page has the richer template language, and it is built around location. An [if] block with [elseif] and [else] shows content for one location, region, county or major-city flag, or for a named Location Set. [random chance="40"] keeps or drops a block with that probability, and the outcome is stored per location. XFields are named variables with one default and per-location overrides, which is how per-location phone numbers and review snippets are done. [cities] lists the nearest other locations by distance, filterable by radius, county and major-city flag, and [map] embeds a Google Map with your own API key. A spintax expression can be named once and reused across the site.

LPagery has no conditional blocks, no weighted random blocks and no distance ordering. If a sentence should only appear for some rows, you put it in its own column and leave the cell empty for the others; a per-row phone number is a column too. Placeholders can be nested. Views build a styled list or grid of related pages on each page, matched on a shared column value and ordered by name, date or a column of your choice. Columns can also set the author, parent page, status and taxonomy terms of each page.

Spintax works in both, and both keep the chosen variant stable across updates: LPagery stores a seed per page, Magic Page caches the chosen index per location. Magic Page can also re-roll spintax on a share of pages over time through its daily cron, which is off by default.

LPagery generates AI text and images per row in the LPagery app and pushes the finished page set into the plugin. You pick the text model per website from six options across OpenAI and Google. Image prompts carry style, format, mood and your brand colours, and text prompts exist in more than twenty languages, picked from your website's country. Every paid licence gets a monthly credit top-up, so there is no API key to set up.

No AI feature was found in Magic Page 7.2. The only third-party keys the plugin asks for are its licence key and a Google Maps key, and the vendor's feature page lists no AI capability either.

LPagery's figures come from the WordPress.org plugin directory on the verification date. Magic Page Plugin is not listed on WordPress.org, so there is no install count, rating or update date from that source. The newest plugin file in the 7.2 zip is dated 2024-10-04, and the plugin header declares no tested-up-to version.

Only LPagery has two render modes with conversion in both directions, Virtual Image URLs that serve one image file under a different name per page, a stall check for dead WP-Cron, Google Sheets sync, AI columns with credits, and an import path for placeholders written for the Multiple Pages Generator plugin.

Only Magic Page has distance as a first-class concept, Location Sets, XFields, a drip that releases locations over a configurable number of days, Export to Static Pages with staggered publish dates, export of the whole site as static HTML, PDF rendering through the vendor API, a front-end location search, and a Google Maps embed per location. Its vendor location databases for 19 countries were not verified in this review.

We walked LPagery's admin with a five-row file and counted what a new user has to learn and click before the first page is live. LPagery needs three concepts (template page, placeholder, source file) and one required setting, the template. Everything else has a default. The first page was live after six clicks on three screens.

Magic Page's admin path could not be measured in the same lab, because no licence key was active there and the master page editor needs one. From the code and the screens we reviewed: the concepts are a master page, locations, radius, Location Sets, XFields and a set of shortcodes; the settings screen holds 29 controls on one page, 15 of them without a label a screen reader can use; and the Magic Page list renders every location term inline in one table cell, with no cap.