MainWP URL Extractor - WordPress Plugin

How to Configure and Use MainWP URL Extractor

MainWP URL Extractor is not meant for ordinary post editing. It is built for a specific practical job: quickly pulling a list of URLs from posts and pages across connected MainWP child sites, formatting that list the way you need, and exporting it to a file. In this guide, we will look at how to prepare your Dashboard, configure the output format with tokens, filter content by site, status, keywords, and dates, verify the output before export, and troubleshoot cases where the data set is smaller than expected.

This guide is intended for site network owners, webmasters, and agencies that already use MainWP or are deciding whether this tool belongs in their workflow. It does not cover purchasing, activating a paid subscription, or bypassing licensing. The focus here is on using an add-on you already have access to inside a working admin dashboard and exporting data without stripping away the context that makes it useful.

The core idea is simple: URL Extractor turns scattered posts and pages across child sites into a manageable list. But its real value does not come from the export button alone. It depends on how carefully you choose the sites, content types, statuses, date range, row template, and separator. One mistake in a single field can leave you with an empty export, an incomplete list, or a file that is awkward to use in a report, indexing workflow, or spreadsheet.

Where URL Extractor Fits in a Multi-Site Workflow

This add-on becomes most useful when manual checking turns into repetitive routine work. If you manage a single site and only need to copy five links, it is usually faster to open the WordPress post list and do it by hand. But when your MainWP Dashboard includes dozens of client sites and you need a regular list of published content, service pages, drafts awaiting review, or posts from a specific period, the manual approach becomes unreliable very quickly.

MainWP URL Extractor runs inside the MainWP Dashboard and works with child sites that are already connected. MainWP documentation explains that the add-on extracts URLs from posts and pages on child sites, supports tokens such as [post.url], [post.title], [post.date], status, author, site URL, and site name, and can then export the results as CSV, TXT, or JSON. In practice, that means the same tool can support several different workflows.

Client reporting without manually copying links

An agency can build a list of published content for a reporting period that includes the site name, post title, public URL, publication date, and author. That file is easy to attach to a client report, pass to a manager, or use as the basis for an internal review. URL Extractor is not a full reporting module, but it handles one focused task well: quickly showing what content exists across the sites and where it was published.

One important distinction: the add-on does not evaluate content quality or check whether a page is indexed. It gives you a list of URLs and related fields. So the right workflow looks like this: export the URL list first, then review it in a search tool, crawler, spreadsheet, or reporting system if needed.

Sending a list into an indexing tool or crawler

The product documentation explicitly ties export functionality to indexing software. In practice, that may mean a list of newly published pages to review after launch, a URL set for a crawler to process, or a batch of pages to compare against a sitemap. In this kind of workflow, output format matters a lot. One tool may work best with one URL per line, another may need a CSV file with extra columns, and a third may expect structured JSON.

Do not pack every possible field into one file "just in case." The more precisely the file matches its purpose, the fewer import problems you will have. If your crawler only needs URLs, keep the row template to a single token: [post.url]. If a manager needs to see which site a link belongs to, add [site.name] and a clear separator.

Taking inventory of posts and pages before a redesign

Another strong use case is getting ready for a migration, redesign, or content cleanup. Before making changes, it helps to pull a list of existing service pages, published blog posts, content still in draft, or older posts from a selected period. That kind of list makes it easier to estimate the workload, separate content by client, and avoid losing pages that still need to remain accessible after the changes.

What makes URL Extractor convenient here is that the filters work at the network level. You choose the child sites, content type, statuses, keyword, and date range, and the output comes from the selected portion of your MainWP network rather than from a single site.

Where the add-on does not replace other tools

It is important to separate URL extraction from site auditing. MainWP URL Extractor is not an SEO crawler. It does not check response codes, canonical tags, redirects, metadata, internal linking, or whether a page appears in the search index. It is also not a general-purpose exporter for all WordPress data. If you need arbitrary custom fields, metadata, products, users, or more complex structures, you should look at dedicated export tools instead.

The right role for URL Extractor is a fast network-wide list of URLs from posts and pages. In that role, it saves time because it works alongside sites that are already connected to MainWP and does not require logging into each site separately.

Who Should Use MainWP URL Extractor and Who Probably Should Not

Any site network tool should be judged not by the length of its feature list, but by how often it solves a real recurring task. MainWP URL Extractor is a good fit if you need URL lists on a regular basis and the source content lives across multiple child sites. If you only need a one-time export once a year from a single site, a dedicated add-on may be more than you actually need.

Web agencies and maintenance teams

For an agency, the biggest advantage is a unified process. A content manager or technical specialist can prepare a file across multiple sites without logging into every admin panel. That is especially useful when clients need proof of publication, a list of changed pages, or a collection of content from a reporting period. The add-on does not replace client communication, but it gives you a verifiable foundation: URL, title, status, author, and site.

If your agency already uses MainWP Pro Reports, URL Extractor can serve as a separate working source for link-based report attachments. Pro Reports compiles reporting data and generates PDFs, while URL Extractor gives you a list of specific URLs that you can attach separately or use for manual review. That is a practical combination, not a developer-promised integration. Each tool has its own job.

Editors and content teams

Editors often do not need access to site settings. What they need is a list of content in a specific state: published, scheduled, draft, pages containing a certain word in the title, or posts from a given period. URL Extractor works well for that kind of oversight if the editor works through someone with Dashboard access or has approved access to MainWP directly. At the same time, admin permissions should be handled carefully. Exporting URLs from a client network can expose site structure and in-progress content.

SEO specialists and indexing teams

For SEO work, the add-on provides a fast input list for further analysis. For example, you can export published service pages across all sites for a single client and then check them in a crawler, Search Console, or a spreadsheet. But URL Extractor itself should not be treated as a visibility analysis tool. It answers the question "which URLs exist in this selected set," not "how well are these URLs performing in search."

When another approach makes more sense

The add-on may be unnecessary if:

• You need to export all post types, custom fields, products, orders, or users rather than just post and page URLs.
• You need to check response codes, redirects, metadata, and internal links, in which case a crawler is the better fit.
• Your MainWP network is not set up yet, child sites are not connected, or the connection is unstable.
• Your team expects automated recurring reports with design, email delivery, and PDFs rather than a manual URL list export.
• You need to work outside the MainWP Dashboard, either directly from each site or from an external system.

Practical rule of thumb: if you can describe the task in advance as "get the URLs of posts or pages from these sites, with these statuses, for this period," URL Extractor is a good fit. If the task sounds more like "run a full SEO audit," you need a different tool.

What to Check Before Installing It on Your MainWP Dashboard

URL Extractor is installed on the MainWP Dashboard site, not on each child site. That is a fundamental point. The add-on extends the central admin panel and pulls data through the existing Dashboard connection to child sites. So preparation starts not with the add-on itself, but with the condition of your MainWP network.

A working Dashboard and connected child sites

MainWP has two core parts: the Dashboard is installed on a separate WordPress site, and MainWP Child is installed on the sites you want to manage. Official documentation recommends running the Dashboard on a separate WordPress installation to reduce the risk of conflicts with a live site. That matters even more for URL Extractor. If the Dashboard is slow or conflicts with other plugins, large URL queries will suffer along with the rest of your MainWP operations.

Before installing the add-on, check the following:

• The Dashboard loads reliably and you have administrator access.
• The child sites you need are connected and visible under MainWP > Sites > Manage Sites.
• For any problematic sites, you have run Test Connection, and a successful response is not masking a redirect, a block, or an SSL issue.
• Sites are organized by tags or clients if exports will be run for selected groups rather than the entire network.

Server resources and network limits

MainWP documentation emphasizes that Dashboard resource requirements grow as your network grows. For an ordinary export across a few sites, that is rarely a problem. But if you manage hundreds of child sites and large numbers of posts, you should avoid heavy operations on weak hosting. MainWP's minimum requirements include current versions of WordPress, PHP, and MySQL, enabled cURL, and enough memory. Recommended values are higher than the minimum, especially for larger networks.

URL Extractor depends both on the Dashboard-to-child-site connection and on the server's ability to process the responses. If your network is large, review MainWP's concurrent request settings in advance. Aggressive parallelism may speed things up on a strong server, but it can also cause timeouts on limited hosting. Lower concurrency is safer for resources, but it increases the time required to complete the operation.

Access control and security

A URL list may include internal pages, drafts, private content, or details about the structure of client sites. It is not a password or payment record, but for an agency it is still operational data. So before configuring the add-on, decide who is allowed to run exports and where the resulting file may be shared.

MainWP describes the platform as self-hosted. The Dashboard runs on your own server, and stable releases do not use telemetry by default. Commercial add-ons may still perform license validation using Dashboard data. There is no reason to present that as a security threat, but administrators should understand the boundary: URL Extractor operates inside the Dashboard, while the handling of the exported file depends entirely on where the user saves it and who receives it.

Plan your first extraction before you run it

A common mistake is opening the add-on and exporting everything immediately. It is much better to describe your first extraction in a single sentence beforehand. For example: "Get published blog posts from Client A sites for the last month in the format site - title - URL." Once you define the goal that clearly, choosing tokens, statuses, sites, date range, and separator becomes much easier. Without a clear target, the export turns into a long file that still has to be cleaned up by hand.

Installing the Add-On and Running the First Check

MainWP URL Extractor is installed the same way as other MainWP add-ons. Official documentation on add-on management describes two main routes: through MainWP > Add-ons > Manage Add-ons or through the standard WordPress plugin installer on the Dashboard site. In either case, install the add-on only on the Dashboard site, not on child sites.

Installing through Manage Add-ons

If your Dashboard is connected to your MainWP account and you have access to the relevant add-on, the built-in add-on manager is the easiest option. The general process looks like this:

1. Open MainWP > Add-ons > Manage Add-ons on the Dashboard site.
2. If needed, confirm that your MainWP account key has already been added and verified.
3. Find URL Extractor in the add-on list or with search.
4. Select the add-on and start the installation.
5. After installation, click Activate Add-ons or activate the specific add-on from its card.

Once activated, a menu entry for the add-on should appear under MainWP. The URL Extractor documentation lists the path as MainWP Dashboard > Add-ons > URL Extractor. If the menu item does not appear, refresh the Dashboard page first, then check the list of installed WordPress plugins and the add-on status in Manage Add-ons.

Installing by uploading the ZIP archive

The manual route works if you downloaded the add-on archive and want to install it like a standard WordPress plugin. On the Dashboard site, open WP Admin > Plugins > Add New, choose Upload Plugin, upload the archive, and activate the plugin. This does not change how it works: URL Extractor must still be used on the Dashboard, not on child sites.

If the archive will not install after upload, check your file upload size limit and the permissions on the wp-content/plugins folder. Do not remove older working add-ons without a Dashboard backup. For manual updates, MainWP notes that reinstalling an add-on normally does not remove its settings, but before making changes to a production Dashboard, having a backup is the sensible move.

Your first post-activation test

Do not start with a large network. Choose one child site where you know published posts or pages already exist. In URL Extractor, use a very simple output format: [post.url]. Leave the separator empty so each item appears on its own line, select Post or Page, choose the Published status, and click Preview Output. If the modal window shows the expected URLs, the basic connection is working.

Quick takeaway: the first test should confirm the data is actually coming from the child site, not whether the export format looks polished. Only after that does it make sense to add more tokens, include multiple sites, add statuses, or build reusable templates.

Configuring Output Format: Tokens, Separators, and Templates

The most important part of MainWP URL Extractor is not the export button. It is the Output format field. This is where you decide what goes into each row of the file. The documentation lists tokens for title, post URL, date, status, author, site URL, and site name. You can type them manually or insert them through the available interface controls. You can also mix tokens with plain text and your own separator characters.

How to think about tokens

A token is a placeholder that gets replaced with a real value from a post, page, or site when the output is generated. For example, [post.url] becomes the public URL of the post, while [post.title] becomes its title. If you include multiple tokens in one row, the output is assembled according to your template.

For a basic URL list, use only [post.url]. For a client report, a row with the site name, title, and URL is usually more useful. For draft review, you may want to add status and date. The more fields you include, the more important your separator becomes. If a title contains a comma, a basic CSV-style layout may become awkward to process manually. Before using a format regularly, open the file in the exact application where it will be used.

Examples of row formats

These examples are not mandatory. They show how the format can be shaped for different needs:

[post.url]
[site.name] | [post.title] | [post.url]
[post.status]; [post.date]; [post.author]; [post.url]
URL: [post.url] | Title: [post.title] | Site: [site.name]

If the file is intended for a Russian-speaking manager, you can add explanatory Russian text around the tokens. If the file will be imported into another tool, a minimal machine-readable format with no extra words is usually the better choice.

How to choose a separator

The Separator field controls how individual records in the output are separated from one another. The documentation notes that if you leave the field empty, each record is placed on a new line. That is a strong default for URL lists that need to be pasted into a crawler or validation tool. If you need a file where records are separated by a specific character, set that separator explicitly.

Try to avoid separators that commonly appear in titles. A vertical bar is easy to read manually, a semicolon often works well for spreadsheets, and an empty separator is usually the best option when you need one URL per line.

Templates for recurring exports

URL Extractor lets you save the values from the Output format and Separator fields as templates. That speeds things up considerably if you have recurring tasks such as a monthly client export, a URL list for indexing, draft review, or service page inventory. Instead of retyping the tokens and separator each time, you can simply select a template from the dropdown and run it.

Give templates clear names. A good name describes the purpose instead of just including the word "export." For example: Client report: site title url, Indexer: URL only, Draft pages with author. If multiple people use the same Dashboard, clear template names reduce the risk of someone accidentally using the wrong format.

When a template should be deleted

Delete a template when it no longer matches the real workflow. An outdated template with the wrong field order can quietly break an export. Someone sees a familiar name, runs the export, passes the file along, and the issue is only discovered later during import or review. If the format changes, it is safer to create a new template with a new name and delete the old one after testing.

How Filters Turn a Site Network into a Precise URL Set

URL Extractor becomes truly useful when you do not export everything blindly, but instead build a targeted selection. The documentation lists filters for content type, status, keyword, date range, and child sites. These settings act like gates: first you define where the data should come from, then which items should be included, and then how each row should be formatted.

Selecting child sites and tags

In the URL Extractor sidebar, you can choose child sites individually or by tag. For agencies, tags are especially helpful. You can group sites in advance by client, topic, team, or project type, so monthly exports do not depend on remembering which exact sites belong to a client package.

If tags are not kept up to date in MainWP, the export may end up incomplete or too broad. Before an important export, open the site list and verify that the right sites are in the correct group. That is faster than having to explain later why a client report is missing content or includes pages from the wrong account.

Content type: posts, pages, or both

The add-on works with posts and pages. That covers most use cases involving blog posts, service pages, information sections, and standard WordPress content. If you need custom post types, WooCommerce products, portfolios, events, or data from other plugins, do not assume URL Extractor supports them unless your version's documentation confirms it. For those cases, dedicated tools or MainWP add-ons designed for that content type are usually the better route.

For your first test, choose just one content type. If you enable both posts and pages at the same time and the output contains too many URLs, it becomes harder to see where the mistake is. Once the format is working, you can broaden the selection.

Using statuses to separate public content from working drafts

The documentation lists the statuses Published, Pending, Private, Scheduled, Draft, and Trash. The status you choose should match the actual purpose of the export. For a URL list that will go into a crawler or indexing workflow, Published is usually the right choice. For editorial review, Draft, Pending, or Scheduled may be more useful. For content cleanup, Trash can be relevant, but use that export carefully so deleted items are not mixed with active content.

Do not mix public and non-public statuses without a reason. If a single file includes both published pages and drafts, an external tool may try to process URLs that should not be available to visitors. For a client report, that is also risky because draft content may look like a publishing mistake.

Keyword and date range

A keyword helps narrow the selection by meaning. For example, you can look for content tied to a specific service, brand, content category, or phrase in the title. But a keyword should not replace careful site and status selection. If the search is too broad, the output will be noisy. If it is too narrow, some of the pages you need may disappear.

A date range is especially useful for reporting periods and content inventory work. In reporting workflows, you usually filter by publication period. In cleanup workflows, you may look for older material. After applying a date filter, always review a few lines in the output. The date may reflect the field used by the add-on and the child site, while the user may expect something different. If the output looks strange, temporarily remove the date filter and compare the selection.

Preview as a required step

The Preview Output button is not just a convenience. It lets you see the future export before saving the file. In the modal window, check the first few rows: are the URLs there, are the fields aligned correctly, is the title missing anywhere, did extra sites slip in, are statuses mixed together? Only export the file once that check looks right.

Do not skip preview before an important export. If the row template or filter is wrong, preview gives you a chance to fix it before the file goes to a client or into another tool.

Practical Workflow: Published Page List for a Client and for Indexing

Consider a real-world workflow that often comes up in agencies: a client wants confirmation of which service pages were published across their sites, and the SEO specialist needs the same list for crawler checks. The task is straightforward, but it is easy to lose context if you export URLs alone without the site name and page title.

Goal

You need a file where each row shows the client site, the page title, and the public URL. The selection should include only published pages associated with the correct client or site group. The final file should be easy to read manually and easy to open in a spreadsheet.

Preparation

Before starting, confirm three things. First, the client's sites should be connected to the Dashboard and grouped by tag or selected manually. Second, the sites must actually contain published pages, otherwise the result will be empty. Third, decide whether you need a date range. If the client wants "all service pages," it is usually better to leave the date blank. If the request is limited to a reporting period, use dates.

Setup steps

1. Open MainWP Dashboard > Add-ons > URL Extractor.
2. In the Output format field, enter [site.name];[post.title];[post.url].
3. Leave Separator empty so each record starts on a new line.
4. In the sidebar, select the client's sites individually or by tag.
5. Choose Page as the content type if you specifically need pages rather than blog posts.
6. Keep only the Published status selected.
7. Add a keyword only if you need to narrow the selection to a specific topic.
8. Click Preview Output and review several lines.
9. Export the result as CSV if the file will be opened in a spreadsheet, or as TXT if you just need a simple list.

Expected output

The file should contain one row for each matched page. The first part of the row should be the site name, the second the page title, and the third the URL. That order is useful because it gives a human reader immediate context for the address. If the client operates multiple sites, a URL by itself is often not enough. You can identify the domain from the address, but a separate site column is much faster to scan in a spreadsheet.

Verifying the output

After export, open the file in a spreadsheet and check five random rows. For each row, open the URL in a browser or crawler. If the page is accessible, the title matches, and the site belongs to the correct client, the selection was built correctly. If some rows are blank or the columns are shifted, go back to the output format and separator.

Common pitfall

If page titles contain semicolons, the separator you chose may shift the columns when the file is opened. In that case, use a different separator inside the row, export a more minimal data set, or import the file into the spreadsheet while manually specifying the delimiter. For automated imports, it is best to create a small test file with a few lines first and confirm that the receiving system reads it correctly.

Working with Post Limits and Large Networks

The official URL Extractor documentation notes an important limitation: by default, the add-on returns a maximum of 50 posts from a single child site. This is not a bug. It is a protective behavior that helps avoid overloading the network and the Dashboard during bulk requests. If you expect hundreds of URLs from each site, you need to account for that limit in advance.

When the 50-item limit becomes a problem

For a standard report of new publications, the limit is often enough. But for a full blog inventory, migration prep, an audit of older pages, or an export of archived content, it may cut the output short. The symptom is simple: you know a child site has far more published posts, but only part of them appear in the export.

Before increasing the limit, check whether you can narrow the selection more safely. You might choose a specific date range, limit the status, work by site groups, or separate posts and pages into different exports. Raising the limit can help, but on weak hosting it can also increase the strain.

The documented filter for increasing the post count

MainWP documents the mainwp_url_extractor_max_posts_number filter, which lets you change the maximum number of returned items. The example in the documentation raises the value to 500. This code should be added on the Dashboard site, not on a child site. The developer recommends using the Custom Dashboard add-on and its PHP tab, which makes the change centralized and easy to reverse.

Below is a small snippet based on the documented filter. It does not modify WordPress core, MainWP core, or the add-on itself. Before using it, back up your Dashboard and test the new value on a small group of sites first.

add_filter( 'mainwp_url_extractor_max_posts_number', 'my_mainwp_url_extractor_limit' );

function my_mainwp_url_extractor_limit() {
    return 500;
}

After saving the change, rerun the same extraction that was previously cut short. If the row count increases and the Dashboard remains responsive, the setting is probably a good fit. If timeouts appear or the server becomes noticeably slower, reduce the number and split the task into multiple exports.

How to choose a safe value

Do not start with an extremely high number right away. For smaller networks, try 100 or 200 first, then 500 if needed. On limited hosting, it is better to work in smaller batches. If a single child site contains thousands of posts, pulling every URL through the Dashboard may not be the best first move. In some cases, it is easier to split the export by time period or use a dedicated exporter on that specific site.

How this relates to MainWP concurrent requests

If the extraction runs across many sites, the load depends not only on the post limit but also on how many child sites the Dashboard processes in parallel. MainWP documentation on concurrent requests recommends lowering the value if the server is weak, the hosting environment limits connections, or child sites are timing out. You should only increase it gradually, and only on a server that can handle it.

For URL Extractor, that turns into a practical rule: if you raise the post limit and run an export across a large group of sites at the same time, do not chase maximum speed. It is better to get a complete file in a few minutes than a fast but incomplete export filled with connection errors.

Checking the Output After Export

An export is not truly successful when the file finishes downloading. It is successful when the file can actually be used for its intended purpose. That matters especially with URL Extractor because the same export may be headed to very different destinations: a client, an editor, an SEO specialist, a crawler, a spreadsheet, or an internal archive. Your verification should match that intended use.

Check the file structure

Open the file in the application where it will really be used. If it is CSV, verify that the columns split correctly. If it is TXT, make sure each line contains one expected URL or one expected set of fields. If it is JSON, check that the receiving system reads the structure without errors. Do not rely on a quick visual look in the browser. Some problems only show up during import.

Pay special attention to characters inside titles. Cyrillic text, quotation marks, commas, semicolons, and vertical bars can all affect downstream processing if the wrong separator is chosen. If the file is going to a client, you can add a brief note explaining the columns, but do not manually alter the original export without keeping a copy.

Check whether the selection is complete

Compare the number of rows against what you expect. If you exported published pages from five sites, you should have at least a rough sense of how many pages each site should contribute. A number that is too small usually points to the wrong status, content type, keyword, date, selected sites, or a post count limit. A number that is too large often means the filter is too broad or blog posts were included when you meant to export pages.

For an important export, it is worth opening a few random URLs from different parts of the file. Do not check only the first rows. If the output is sorted by site or date, the first few rows may look correct while the real problem appears later on.

Check privacy and whether the file is appropriate to share

Before sending the file to a client or outside specialist, remove anything the recipient does not need. If the export includes authors, draft statuses, internal site names, or operational pages, ask yourself whether that information really belongs outside your team. URL Extractor helps you gather the data, but responsibility for sharing it still rests with the administrator.

Good habit: keep the original export separately, and make a copy with a clear filename and only the columns you actually need for sharing. That makes it much easier to reconstruct the context later if someone asks where a specific link came from.

Using It with Reports, Spreadsheets, and Crawlers

MainWP URL Extractor rarely stands alone. In most cases, the file it generates becomes the starting point for the next step. That is why it helps to decide in advance where the output is going. That choice affects the row format, separator, token set, and even whether saving a template makes sense.

With Pro Reports for client reporting

MainWP Pro Reports is a separate add-on for building client reports. Its job is broader: it gathers data, uses templates, can generate PDFs, and works with client information. URL Extractor should not replace that module, but it can provide a link-based attachment to the report. For example, Pro Reports can show completed work and general activity, while URL Extractor can provide the exact list of published content for the same period.

The safe workflow looks like this: configure the report in Pro Reports first, then export the URLs for the relevant content separately, open the file, remove any unnecessary fields, and attach it to the email or internal task. The possible conflict here is not technical but organizational. If the report and the URL list use different date ranges or different site groups, the client will notice the mismatch. So those periods and site groups need to be checked manually.

With spreadsheets for manual review

A spreadsheet is useful when the list needs comments, sorting, assignment by owner, or review status markers. For that purpose, it is better to export more than just the URL. Include the site name, title, and status so an editor or SEO specialist can immediately see what they are working with. If you export URLs alone, some of that context has to be reconstructed from the domain and path.

A good spreadsheet format is [site.name];[post.status];[post.title];[post.url]. After opening the file, you can name the columns in Russian and add internal working columns such as "Checked," "Comment," and "Action." Those internal columns are best added in a copy of the file so the original export stays clean.

With a crawler or URL validation tool

If the file is intended for a crawler, do not overload each row with unnecessary fields. One URL per line is usually enough. Many crawlers can import URL lists, crawl them, and then export response codes, titles, canonical URLs, metadata, and internal links. In that workflow, URL Extractor is responsible for the source list, while the crawler handles the technical verification.

For a large list, use a two-step check. First export 10 to 20 URLs and confirm that the crawler accepts the format. Then run the full file. This matters especially when the separator or encoding could affect import behavior.

With sitemaps and search tools

Sometimes it is useful to compare a URL Extractor export against a sitemap or search console reports. For example, if published pages exist in MainWP but do not appear in the sitemap, the problem may not be URL Extractor at all. It may be related to the SEO plugin, exclusion settings, page status, or sitemap caching. In that situation, the add-on helps you see one specific layer of truth: which posts or pages the selected child sites return under the filters you applied.

Do not draw conclusions about search visibility based on the export alone. A URL may exist and be published but still not be indexed because of noindex, a canonical URL, a redirect, a response error, robots.txt, or the page's overall quality. Those checks require external tools.

Why an Export May Be Empty, Incomplete, or Hard to Use

Troubleshooting URL Extractor usually starts with a simple question: is the issue caused by data selection, the MainWP connection to child sites, the row format, or the way the file is being used afterward? Once you separate those layers, fixing the problem is much faster. The cases below are especially typical for network-wide URL extraction through MainWP.

No URLs appear in preview

Symptom: after clicking Preview Output, the modal window is empty or shows fewer rows than expected. Possible causes include no site being selected, the wrong content type, a status that does not match the actual content state, a keyword that is too narrow, a date range that excludes the needed items, or a child site that is not responding to the Dashboard.

What to check

• Whether at least one child site or a tag containing the required sites has been selected.
• Whether the site actually contains content of the selected type: Post, Page, or both.
• Whether the chosen status matches the actual content state.
• Whether the keyword or date range is narrowing the selection too much.
• Whether Test Connection succeeds for the problematic child site.

How to fix it: simplify the selection to one site, one content type, the Published status, and the [post.url] format. If that works, add the filters back one by one. If it still does not work in the simple version, move on to checking the MainWP connection itself.

The export cuts off part of the content

Symptom: you know the site contains more content, but the output only includes a limited number of rows. With URL Extractor, that may be caused by the documented cap on the number of items returned from one child site. In that case, the issue is not the export process itself, but the upper bound on the selection.

How to fix it: first narrow the selection using dates, status, or content type. If you truly need a larger export, use the documented mainwp_url_extractor_max_posts_number filter on the Dashboard site and increase the value gradually. If timeouts start after increasing it, lower the value again or split the task across multiple runs.

The file opens in a spreadsheet with shifted columns

Symptom: after opening the CSV, part of the title lands in the wrong column, the URL breaks incorrectly, or the rows become hard to read. In most cases, the separator is the problem: the chosen character also appears inside titles or other text included in the row.

How to fix it: try a different separator inside the row, reduce the number of tokens, export a test file, and open it while manually specifying the delimiter. For a simple URL list, do not add extra text. One token, [post.url], with one item per line is usually safer than a complex layout.

The URLs are there, but some pages do not open publicly

Symptom: the URL is present in the file, but when you open it in a browser or crawler, some addresses return an error, redirect, or restricted page. URL Extractor pulls data from selected posts and pages, but it does not guarantee that an outside visitor will see the page exactly as expected. The page may be private, access-restricted, redirected, cached incorrectly, affected by a theme issue, using changed permalink rules, or otherwise unavailable.

How to fix it: check the exported status, open the page from the child site's admin panel, and compare the public URL. For technical verification, use a crawler or a response-code checking tool. If the problem is access-related, do not try to work around it through export. Fix the publication or access settings on the site itself.

One or more sites keep dropping out of the output

Symptom: the export works for most of the network, but specific child sites never return data. The cause may be the MainWP connection, a firewall block, SSL, DNS, a security plugin, or cache behavior. MainWP documentation recommends starting with Test Connection and interpreting the HTTP response codes.

How to fix it: inspect the site in MainWP > Sites > Manage Sites, run Test Connection, and review the response code and message. If the request is being blocked, temporarily check the security layer, .htaccess rules, cloud firewall settings, and the Dashboard IP address. For stable operation, do not leave temporarily disabled protections turned off.

Date picker controls stopped working after an update

Symptom: the date field or calendar behaves incorrectly. The URL Extractor changelog notes a fix for broken date picker controls in the current branch of the add-on. If the issue looks like an interface problem, check for an available update first, then look for a JavaScript conflict inside the Dashboard.

How to fix it: update the add-on and Dashboard through the standard process, clear your browser cache, temporarily disable browser extensions that interfere with admin pages, and test in a different modern browser. If the error continues, record the exact steps, browser, and a screenshot before contacting support.

When it is better to roll back a change

A rollback makes sense if the Dashboard becomes noticeably slower after raising the post limit, timeouts start appearing, or other MainWP operations become unstable. Remove or comment out the filter, restore the previous concurrent request setting, and rerun the export in smaller batches. In troubleshooting, the goal is not to force one huge file through at any cost. The goal is to get a verifiable result without putting the working Dashboard at risk.

Safe Improvements and Better Working Habits

URL Extractor is not the kind of tool that benefits from dozens of technical customizations. Its strength comes from the right template, the right filters, and proper output review. Still, there are a few practical habits that make it much more reliable without touching WordPress core, MainWP core, or the add-on itself.

Separate templates by end recipient

Create different templates for client delivery, SEO review, and internal editorial work. A client-facing file should usually be easy for a person to read: site, title, URL, and possibly status. A crawler usually needs only one URL per line. An editor may benefit from author, status, and date. One universal template may seem convenient, but in practice it creates noise and increases the chance of mistakes.

Keep a log of important exports

If exports are used in reporting, keep a short note alongside them: which sites were selected, which statuses were used, what period was covered, and which template was applied. You can store that in a task system, spreadsheet, or internal knowledge base. A log like that helps explain discrepancies if a client or colleague asks a few days later why a specific page was missing from a file.

Use a test selection before a bulk export

Before running a large export, run a small one first: one site, one status, a short date range. Confirm that the format is correct, then expand the selection. This is especially helpful after changing a template, updating the add-on, or increasing the limit through a filter.

Do not keep unnecessary working data in shared folders

A URL file may look harmless, but it often reveals client site structure and internal content. Keep the original files in a location accessible only to your team, and share a cleaned copy externally. If the file is no longer needed, delete it according to your team's data handling rules. Do not attach exports containing drafts to client emails without reviewing them first.

Similar Tools and When They Are a Better Fit

MainWP URL Extractor does not really have a direct one-to-one equivalent because it works inside a MainWP network and focuses specifically on post and page URLs from child sites. Still, there are nearby tools that solve related problems from a different angle: reporting, full data export, spreadsheet-based editing, and technical crawling.

When MainWP URL Extractor Is the Right Choice

MainWP URL Extractor is worth using when you need a controlled list of URLs from posts and pages across multiple child sites and MainWP is already your working hub for managing the network. It is especially useful for agencies, editors, and SEO specialists who regularly need published page lists, content for a reporting period, drafts under review, or source URLs for further analysis.

Before using it on a recurring basis, set up three things: clear output templates, well-organized site groups, and a short review process for checking the output. Do not turn every export into "everything at once." A good export answers one specific question and is immediately usable for the next step, whether that is a report, spreadsheet, crawler, or internal review.

If your task depends more on full export of any WordPress data, bulk editing, automated PDF reports, or technical SEO auditing, URL Extractor is better treated as one piece of the workflow rather than the only tool in it. But when you need a fast, repeatable URL selection across a MainWP network, it solves the job more cleanly than logging into each site one by one.

Once your Dashboard is prepared, your connections are verified, and your first workflow is defined, you can download MainWP URL Extractor, install it on the MainWP Dashboard, and start with a small test export. That approach is safer than jumping straight into a large bulk export because it lets you confirm that the filters, tokens, and file format work exactly the way your team needs them to.