IndexNow 1.2.0: Opening Indexing Notifications to Geeklog Plugins

The IndexNow plugin for Geeklog is evolving with version 1.2.0. This release goes beyond submitting articles and static pages: it introduces a generic interoperability mechanism that allows other Geeklog plugins to notify search engines when their own public content is created, updated, or deleted.

The goal is simple: if a Geeklog plugin knows that one of its public items has changed, it should be able to announce that change without the IndexNow plugin needing to understand its database structure, internal tables, or routing logic.

This creates a cleaner and more extensible way for Geeklog plugins to cooperate.

IndexNow 1.2.0 is available from the Geeklog Plugins repository:

https://github.com/Geeklog-Plugins/IndexNow

A Complement to Geeklog Core, Not a Replacement

It is important to clarify the purpose of this plugin.

Modern Geeklog already includes IndexNow support through its core distribution and XML Sitemap functionality. The standalone IndexNow plugin is therefore not intended to compete with, replace, or duplicate the work already available in Geeklog Core.

Its role is different.

Many Geeklog websites have been running for years and cannot necessarily move immediately to the latest environment. Some still depend on older themes, plugins, PHP versions, hosting configurations, or custom developments.

IndexNow 1.2.0 therefore deliberately targets a wide compatibility range:

• Geeklog 2.1.1 through Geeklog 2.2.2
• PHP 5.6 through PHP 8.1

This makes it possible to bring modern indexing notifications and new plugin interoperability features to existing Geeklog installations while they progressively modernize.

Ideally, some of these concepts may eventually become useful directly in Geeklog Core. Until then, the plugin provides a practical environment where they can be implemented, tested and improved without requiring older websites to immediately change their entire platform.

Why Plugin Content Matters for Indexing

A Geeklog website is rarely made only of stories and static pages.

Plugins can create many kinds of public resources: directories, media, locations, documents, products, events, discussions or entirely new content types.

From the point of view of a search engine, these plugin-generated pages can be just as important as a standard Geeklog article.

Until now, an IndexNow integration could easily become tightly coupled to individual plugins. The IndexNow code would need to know where another plugin stores its data, how it constructs URLs and what happens when an item is deleted.

That approach does not scale.

IndexNow 1.2.0 instead follows a simple rule:

the plugin that owns the content remains responsible for describing that content and its canonical URL.

IndexNow only listens for Geeklog lifecycle events and asks the owning plugin for the information it needs.

Using Geeklog's Existing Plugin Lifecycle

Geeklog already provides an important part of the solution through its plugin API.

When an item is created or updated, a content plugin can announce the event with:

PLG_itemSaved($id, 'pluginname');

When an item is removed:

PLG_itemDeleted($id, 'pluginname');

IndexNow 1.2.0 listens to these events generically.

This means the IndexNow plugin does not need a dedicated section such as:

if this is plugin A...
if this is plugin B...
if this is plugin C...

Instead, it receives two important pieces of information:

content type + item ID

For example:

pluginname / 123

The owner of that item can then provide its public URL.

What a Content Plugin Should Provide

A plugin does not necessarily need major changes to participate in this mechanism.

The exact requirements depend on what the plugin already implements, so plugin authors should first check their existing Geeklog API callbacks.

The most important capability is the ability to return information about an item through the standard Geeklog plugin mechanism, in particular its canonical public URL.

A typical implementation can expose information through:

plugin_getiteminfo_PLUGIN($id, $what, $uid = 0, $options = array())

Useful information can include:

id
title
url
description
date-created
date-modified
type
subtype

For IndexNow, the canonical URL is the essential element.

Where appropriate, a plugin can also provide an ID-to-URL callback:

plugin_idtourl_PLUGIN(...)

This is especially useful when an URL can be reconstructed directly from an item identifier.

The general flow then becomes:

Content is saved
       ↓
PLG_itemSaved()
       ↓
IndexNow receives type + ID
       ↓
Geeklog asks the owning plugin for the URL
       ↓
Canonical public URL
       ↓
IndexNow submission

No SQL table belonging to another plugin needs to be queried.

Handling Deleted Content

Deletion is particularly interesting.

Once a database row has been deleted, asking the content plugin to look it up may obviously be too late.

For content where this matters, a plugin can use an identifier from which the former public URL can still be determined.

For example, an identifier could be namespaced:

item:123

The plugin can then reconstruct:

https://example.com/plugin/index.php?mode=item&id=123

even if item 123 is no longer stored in its database.

IndexNow can therefore notify search engines that the URL changed or disappeared without knowing anything about the plugin's database.

This behavior has already been tested successfully with real plugin content, including creation, updates and deletion, with IndexNow returning HTTP 200 responses.

Namespaced IDs for More Complex Plugins

Some plugins manage several kinds of resources.

A simple numeric ID may therefore not always be enough.

IndexNow 1.2.0 supports identifiers such as:

item:123
category:8
resource:42

This technique is particularly useful because it remains compatible with the lifecycle API available in Geeklog 2.1.1 while still allowing a plugin to identify different resource types.

The event can remain very simple:

PLG_itemSaved('item:123', 'pluginname');

The receiving plugin still knows exactly what kind of object changed.

A Persistent Submission History

Another major addition in IndexNow 1.2.0 is submission history.

The plugin now records IndexNow activity in its own Geeklog-prefixed database table.

For each attempt it can store information such as:

content type
item ID
subtype
event
URL
HTTP response
status
message
submission date

Possible statuses include:

success
failed
skipped

A success means IndexNow accepted the request.

A failed entry helps identify URL resolution or communication problems.

A skipped event is also useful: when no IndexNow key is configured, the plugin can still record that the Geeklog lifecycle event occurred and that the URL was successfully resolved.

This makes development and testing much easier.

A Native Geeklog Administration List

The submission history is displayed using Geeklog's native administrative list system.

Administrators therefore get familiar features including:

• search;
• sortable columns;
• pagination;
• configurable list size;
• status filtering;
• event filtering;
• content-type filtering.

It becomes possible, for example, to search for a particular item, display only deleted URLs, or inspect failed submissions.

The history retention period can also be configured. It can be limited to 30, 90, 180 or 365 days, or kept indefinitely.

Better Plugin Interoperability Beyond IndexNow

Perhaps the most interesting aspect of this work is that the mechanism is not really specific to IndexNow.

Consider the identity:

type + ID + canonical URL

Once a content plugin can expose this information and announce lifecycle events, other Geeklog services can potentially use the same contract.

A future service could ask:

• What is this item?
• What is its canonical URL?
• When was it modified?
• Who owns it?
• What type of content is it?
• Has it just been created, updated or removed?

That can become useful for sitemaps, notifications, analytics, search visibility tools, content relationships, automation or future orchestration plugins.

IndexNow is simply one consumer of that interoperability.

This also keeps responsibilities clean.

A content plugin owns its content.

It does not need to know how IndexNow works.

IndexNow does not need to understand the content plugin's database.

Both communicate through the Geeklog plugin API.

Supporting the Long Life of Geeklog Sites

Geeklog has always had one particularly valuable characteristic: installations can remain useful for a very long time.

That strength also creates a challenge.

A website that has been running for many years cannot always upgrade its CMS, PHP version, plugins and theme simultaneously.

The compatibility target of IndexNow 1.2.0 is therefore intentional.

Supporting Geeklog 2.1.1 through 2.2.2 and PHP 5.6 through 8.1 creates a bridge between older installations and newer Geeklog development practices.

It gives administrators an opportunity to introduce newer capabilities progressively instead of treating modernization as an all-or-nothing migration.

At the same time, the implementation stays based on Geeklog mechanisms rather than building a separate framework beside the CMS.

An Invitation to Plugin Developers

Plugin developers interested in this interoperability do not need to add IndexNow-specific HTTP code to their plugins.

The preferred approach is much simpler.

A content plugin should, where appropriate:

1. expose its public item information through Geeklog's plugin API;
2. provide a reliable canonical URL for its public content;
3. call PLG_itemSaved() after meaningful creations or updates;
4. call PLG_itemDeleted() when public content is removed;
5. where necessary, make deleted-item URLs deterministically recoverable from the item ID.

IndexNow can then take responsibility for the actual submission.

Plugin developers should first review what their plugin already implements, because some or all of these Geeklog mechanisms may already be available.

The objective is not to impose another private API. It is to make better use of the interoperability mechanisms Geeklog already gives us.

Available Now

The updated IndexNow plugin can be found in the Geeklog Plugins organization:

https://github.com/Geeklog-Plugins/IndexNow

Version 1.2.0 represents more than an IndexNow update. It is also an experiment in making Geeklog plugins communicate through small, stable and reusable contracts.

Geeklog Core already provides IndexNow support for modern installations. This plugin complements that work by bringing additional functionality and broader backwards compatibility to sites running Geeklog 2.1.1 through 2.2.2 and PHP 5.6 through 8.1.

Perhaps, in time, some of these ideas will find an appropriate place directly in Geeklog Core.

Until then, they can be tested where Geeklog has always been strongest: in real websites, with real plugins, and with a community that continues to evolve the platform without forgetting the sites that have relied on it for years.