The add-on does not create pages in Concrete... they are all virtual. This prevents clutter, and makes sure that the add-on is always up-to-date with changes you've made in WordPress.

However, this does mean that it doesn't work with the default site indexing, since it is not writing pages to the database.

One idea was to provide an option to allow the add-on to generate pages automatically. It would be a "job" in Concrete that would process the blog pages that are available in WordPress, and generate "fake" pages for each one.

This would provide the paths which are necessary, but when Concrete accesses one of these pages, it would redirect to the actual blog page, like it does right now.

Does this sound like it would be a good idea, or should it be handled differently?

As long as there is some type of internal cleanup process that handles the page generation, I think that *could* work.

For example, if we change the post slug after the post has been published, the job would need to manage this accordingly (delete the old page and create a new page).

As long as it works with pretty links, I think this could be feasible.