MAGENTO 2 · URL SUBMISSIONS · QUEUE · GOOGLE API

Manage URL submissions in one Magento queue.

Kowal Google Indexing API

Collect addresses from the panel and integrations, control duplicates, scheduling and sending limits. Keep a history of Google's responses and clearly distinguish acceptance of a submission from page indexing.

Dry Run · Retry and logs · API scope defined by Google

HOW IT WORKS IN PRACTICE

01 · Configure access and scope
Check the service account, hosts and allowed Store Views.

02 · Add addresses to the queue
Use imports, bulk actions or buttons.

03 · Monitor processing
Cron handles sending, limits, results and retries.

How does your store benefit?

Explore the module's features, use cases, and settings.

Notify Google faster about store changes

Module Kowal Google Indexing API for Magento 2 helps submit URLs to Google more efficiently when they have been added, changed or should be removed from the index. Instead of relying solely on Google's standard recrawling, an administrator can send selected addresses to a queue processed through Google Indexing API.

The solution is particularly useful in stores with frequent changes to content, offers, product availability, CMS pages, landing pages or blog posts. It organizes the whole process: collects addresses from different Magento areas, checks them, removes duplicates, controls limits and records communication with Google.

Google Indexing API is officially intended for pages with structured data JobPosting and BroadcastEvent. Submitting a URL through the API does not guarantee indexing, rankings or acceptance of every address by Google. The module supports technical URL submission; it does not replace proper technical SEO, XML sitemaps, canonicals, robots, hreflang or internal linking.

Better control over address submissions

The module gives administrators one place to manage URLs waiting to be sent to Google. Products, categories, CMS pages, manual URL imports and future sources can use the same queue, avoiding separate integrations for each content type.

Less manual work after store changes

Addresses can be added to the queue directly from the Magento administration panel. Bulk actions and buttons on selected entity edit screens let administrators quickly request indexing of a single page or a larger group of addresses.

Safer use of API limits

Google Indexing API has limits. The module considers daily and per-minute limits, cron batch size and sending delay. Addresses are sent in an orderly way, helping reduce unnecessary consumption of the available quota.

Fewer duplicates and repeated submissions

Before saving an address, the module normalizes and validates the URL and checks whether the same address is already waiting in the active queue. If a similar submission exists, the system can update it or mark it as deduplicated. This reduces queue clutter and unnecessary Google requests.

More transparency for the team

Each submission has a status, source, action, priority, attempt count, scheduled time and Google response information. Administrators can see which addresses are waiting, successfully sent, due for retry or failed permanently.

Easier troubleshooting

The module logs communication with Google API, including request type, endpoint, payload, HTTP status, response content and duration. This helps analyze configuration, permission, limit and submitted URL errors.

Ready for store growth

The module's architecture uses a shared scheduler and queue. New URL sources do not need to communicate directly with Google. They pass addresses to the queue, and the existing processor handles validation, scheduling, limits, retries and logging.

How the module works in practice

The module acts as an intermediary between Magento and Google Indexing API.

An administrator or integration selects URLs to submit.
The module normalizes and validates URLs, checking aspects including scheme, host and allowed sources.
Valid addresses enter the central queue with the appropriate status, action and sending time.
Magento cron periodically retrieves records ready for processing.
The queue processor respects limits, priorities, delays and record locks.
The module submits the request to Google Indexing API or processes it in dry-run mode.
Google's response is saved with the queue record and in API logs.
For temporary errors, the module can schedule a delayed retry.

URL sending does not depend on a single click or a direct request from the administration panel. The whole process is queued, auditable and more resilient to temporary API problems.

Main features

central URL queue for different content sources,
support for the actions URL_UPDATED and URL_DELETEDerrors,
manual import of multiple URLs from the administration panel,
bulk actions for products and CMS pages,
indexing submission buttons on product, category and CMS page edit screens,
optional Amasty Blog integration as a separate module,
URL normalization and validation,
allowed host whitelist,
store view support and identification of the submission source,
deduplication of active submissions,
sending delay, or indexing lag,
priorities and the action Transmit Nowerrors,
cron processing,
daily and per-minute limit control,
delayed retries for temporary errors,
queue statuses: schedulederrors, pendingerrors, processingerrors, successerrors, retryerrors, failed_permanenterrors, cancellederrors,
dry-run mode for safe testing without sending real requests,
API logs and log retention,
test credentials and metadata in the setup assistant.

Who this module is for

The module is suitable for Magento 2 stores that:

frequently update product offers,
publish or change many CMS pages,
perform SEO work across multiple content types,
need control over which URLs have been submitted to Google,
want to reduce manual submission management,
operate in multistore or multilingual environments,
need a clear audit of Google requests.

It is particularly valuable for e-commerce, SEO and administration teams seeking a shared, organized process for notifying Google of store changes.

New or changed products

After adding a product or significantly changing an existing one, administrators can send its address to the queue. The module handles submission recording, the appropriate delay, deduplication and subsequent sending.

Updating CMS pages and landing pages

When marketing publishes a new campaign, promotion or information page, its URL can be added to the queue without manual work outside Magento.

Managing addresses after site changes

The module supports update submissions and also the action URL_DELETED. This allows notifying Google of addresses that should be removed from the index, provided the scenario complies with API usage rules.

Bulk SEO actions

For larger changes, such as updating many products, migrating content or refreshing categories, administrators can use bulk actions and monitor progress in the queue.

Business impact

The module gives teams greater control over technical change submissions to Google. Scattered, manual, hard-to-verify activities become one process: an address enters the queue, passes validation, is sent within the limits and its result is visible in the administration panel.

The module's main value is organizing work around indexing: fewer accidental requests and duplicates, better diagnostics and clearer responsibility for what has been submitted to Google.

Official Google Indexing API scope

According to Google documentation the API is for pages with JobPosting or BroadcastEvent embedded in VideoObject. Ordinary product, category, CMS and blog pages are outside the officially supported scope, even though the module can technically queue their URLs.

HTTP 200 and success status indicate a successful submission. Metadata confirms notification, not the date a page was indexed or removed. For URL_DELETED, the address should return 404/410 or contain noindex.

Setup assistant and initial launch

Stores → Configuration → Services → Google Indexing API covers the service account, hosts, Store Views, limits and dry-run. You need the API enabled in Google Cloud, a verified Search Console property and appropriate service account permissions.

Marketing → Google Indexing API provides Setup Assistant, Indexing Queue and Import URLs. Start with dry-run and credentials and metadata tests, check cron, then enable real sending for the appropriate scope.

Amasty Blog integration and new sources

The bulk action for Amasty Blog is in a separate package, kowal/module-google-indexing-api-amasty-blog. The core module does not require Amasty Blog.

A new source can pass a URL, URL_UPDATED or URL_DELETED action, source, entity and store ID through IndexingRequestSchedulerInterface. The shared queue takes over scheduling, validation, deduplication and retries.

Installation via Composer

Package kowal/module-google-indexing-api, module Kowal_GoogleIndexingApi. After configuring access to the Kowal repository, install the package, enable the module, update Magento, and clear the cache. In production, include compilation and static content deployment in accordance with the store's deployment process.

From configuration to results

1. Configure access and scope
Check the service account, hosts and allowed Store Views.

2. Add addresses to the queue
Use imports, bulk actions or buttons.

3. Monitor processing
Cron handles sending, limits, results and retries.

Control the submission process

Import addresses allowed by API rules and check them in dry-run first. Verify the source, action and scheduled time in the queue.

Once sending is enabled, analyze responses and retries. Success status confirms request acceptance, not the page appearing in Google results.

Organize submissions and API diagnostics

Want to tailor the module to your store? Ask about implementing Kowal Google Indexing API and discuss the configuration or any extensions you need.

Google Indexing API for Magento 2 - installation and configuration

1. Important information before implementation

The module integrates Magento 2 with Google Indexing API and allows you to add URLs to a central submission queue. The queue is processed by Magento cron, and each submission is validated, deduplicated, rate-limited, and logged.

According to Google documentation, Indexing API is officially intended primarily for pages with structured data:

JobPostingerrors,
BroadcastEventembedded inVideoObject.

Using the API for products, categories, CMS pages, or blog posts does not guarantee indexing or rankings in search results. The module should be treated as a technical tool for submitting URLs, not as a replacement for XML sitemaps, correct canonicals, robots, hreflang, internal linking, and overall SEO quality.

Official Google resources:

2. Requirements

Before installation, make sure that the environment meets the requirements:

Magento 2.4.x,
PHP 8.1 or newer,
Composer,
working Magento cron,
ability to install thegoogle/apiclienterrors,
administrative access to Magento,
Google Cloud project with Indexing API enabled,
property in Google Search Console verified for the store domain,
Google service account added as an owner in Google Search Console.

The module requires the package:

google/apiclient:^2.16

The package is declared in the module'scomposer.json, so Composer should install it automatically.

3. Module installation

3.1. Installation via Composer

Add the Kowal Composer repository to the Magento project:

You will receive the access details for the Composer repository, the customer's email address and license token, by email after purchase. They are also available in the customer panel after logging in at kowal.store. Replace TWOJ_EMAIL_KLIENTA with your account email address and TWOJ_TOKEN with the token you received. Run the commands in the Magento root directory.

composer config repositories.kowal composer https://repo.kowal.store

Configure the access details for the Kowal Composer repository:

composer config http-basic.repo.kowal.store "TWOJ_EMAIL_KLIENTA" "TWOJ_TOKEN"

Install the package:

composer require kowal/module-google-indexing-api

Enable the module:

bin/magento module:enable Kowal_GoogleIndexingApi

Run the database schema update:

bin/magento setup:upgrade

Clear the cache:

bin/magento cache:flush

In production mode, additionally run:

bin/magento setup:di:compile
bin/magento setup:static-content:deploy
bin/magento cache:flush

3.2. Local installation in`app/code`

If the module is installed without Composer as local code, place it in the directory:

app/code/Kowal/GoogleIndexingApi

Then install the Google API Client dependency in the Magento project:

composer require google/apiclient:^2.16

Enable the module and run the standard Magento commands:

bin/magento module:enable Kowal_GoogleIndexingApi
bin/magento setup:upgrade
bin/magento cache:flush

For production:

bin/magento setup:di:compile
bin/magento setup:static-content:deploy
bin/magento cache:flush

3.3. Verifying the installation

Check whether the module is active:

bin/magento module:status Kowal_GoogleIndexingApi

After a successful installation, the following should be available in the admin panel:

Stores > Configuration > Kowal > Google Indexing APIerrors,
admin menuGoogle Indexing API > Indexing Queueerrors,
Google Indexing API > Import URLserrors,
Google Indexing API > API Logserrors,
Google Indexing API > Setup Assistant.

The following tables should be created in the database:

kowal_google_indexing_queueerrors,
kowal_google_indexing_api_log.

4. Preparing Google Cloud and Search Console

4.1. Creating a Google Cloud project

Go to Google Cloud Console.
Create a new project or select an existing project used for the store.
Enable the API:

Indexing API

Without the API enabled, the module will not be able to send submissions correctly.

4.2. Creating a service account

In Google Cloud, go toIAM & Admin > Service Accounts.
Create a new service account.
Generate a key in JSON format.
Download the JSON file and store it securely.

The module requires the JSON to contain at least the following fields:

typeerrors,
project_iderrors,
private_keyerrors,
client_email.

Fieldtype field must have the value:

service_account

4.3. Adding the service account as an owner in Search Console

Open Google Search Console.
Select the property corresponding to the store domain.
Make sure the property is verified.
Add theclient_emailaddress from the JSON file as an owner of the property.

Example service account address:

my-service-account@project-name.iam.gserviceaccount.com

If the service account is not an owner of the Search Console property, Google may return permission errors, for example no confirmation of URL ownership.

5. Module configuration in Magento

The configuration is located in:

Stores > Configuration > Kowal > Google Indexing API

The configuration supports Magento scopes:

Default Config,
Website,
Store View.

This allows you to have separate settings for different stores or store views if the project requires it.

6. General section

Enable

API Log Retention Days

No

Enables or disables the module.

When the field is set toNo, cron does not process the queue. Addresses may exist in the database, but the queue processor will not send them to Google.

It removes entries older than the number of days set in this field.

during the first configuration, setNoor leaveDry Run = Yeserrors,
after successful tests, setYes.

Dry Run

API Log Retention Days

Yes

Test mode. WhenDry Runis enabled, the module processes queue records and saves statuses and logs, but does not send an actual submission to Google.

This is the safest mode for the first launch, configuration testing, and checking whether URLs are added to the queue as expected.

It removes entries older than the number of days set in this field.

always run the first tests withDry Run = Yeserrors,
disableDry Runonly after checking credentials, allowed hosts, the queue, and logs.

7. Google Access Credentials section

Credentials Source

API Log Retention Days

Encrypted configuration value

Defines where the module gets the Google service account JSON from.

Available options:

Option	Technical value	Field
`Encrypted configuration value`	`config`	The JSON is pasted into the Magento configuration and saved as an encrypted sensitive config value.
`Uploaded JSON file`	`file`	The JSON is uploaded as a file and stored outside the`pub`directory, in`var/google-indexing`.

It removes entries older than the number of days set in this field.

for simple implementations, you can use the encrypted value in the configuration,
for environments with file access control, uploading the JSON file may be more convenient.

Service Account JSON

Visible whenCredentials Source = Encrypted configuration value.

Paste the full contents of the Google service account JSON file into this field.

The module validates the JSON before saving. It checks:

correct JSON format,
presence of thetypeerrors,project_iderrors,private_keyerrors,client_emailerrors,
the valuetype = service_account.

The value is saved as encrypted Magento configuration.

Service Account JSON File

Visible whenCredentials Source = Uploaded JSON file.

Allows you to upload the Google service account JSON file.

The module:

accepts only files with the.jsonerrors,
validates the file contents,
checks the required fieldstypeerrors,project_iderrors,private_keyerrors,client_emailerrors,
saves the file outside the public directory, invar/google-indexingerrors,
attempts to set file permissions to0600if the file driver allows it.

The file is saved with a name based on the configuration scope, for example for the global scope:

var/google-indexing/service-account-default-0.json

Google Cloud Project ID

Text field for the Google Cloud project identifier.

In the current module implementation, the main authorization is based on the data from the service account JSON. TheGoogle Cloud Project IDfield serves an informational and configuration-organizing purpose, especially when the store uses several environments or several Google Cloud projects.

It removes entries older than the number of days set in this field.

enter theproject_idvalue from the JSON file,
use separate Google Cloud projects for production and test environments if such separation is used in the project.

8. Queue and Limits section

Daily Publish Limit

API Log Retention Days

Defines the maximum number of publish submissions that the module can perform per day.

The limiter counts requests of type:

publisherrors,
publish_dry_run.

If the limit is reached, the queue processor will not pick up more records for sending until the next daily window.

It removes entries older than the number of days set in this field.

Recommendation:200if the project uses Google's default onboarding limit,
increase the value only if the Google Cloud project has an approved higher limit,
setting0blocks sending because the available number of slots will be0.

Requests Per Minute Limit

API Log Retention Days

Defines the maximum number of publish requests per minute.

The module compares this value with the number of requests saved in logs from the last minute. If the per-minute limit is used up, cron will not process additional records in the current run.

It removes entries older than the number of days set in this field.

for a typical implementation, leave the default value,
decrease the value if you want to put a more conservative load on the API,
do not set0unless you want to temporarily stop sending.

Cron Batch Size

API Log Retention Days

Defines the maximum number of queue records processed in a single cron run.

The actual number of processed records is also limited by:

Daily Publish Limiterrors,
Requests Per Minute Limiterrors,
the number of records ready to be sent,
the status andscheduled_at.

It removes entries older than the number of days set in this field.

20is a safe starting value,
for large queues, you can increase the value, but only while taking Google limits into account.

Default Indexing Lag (minutes)

API Log Retention Days

Defines the default delay between adding a URL to the queue and the moment when it can be sent.

The delay helps to:

reduce duplicates,
avoid sending after every minor change,
give the administrator time to correct content,
better manage the API limit.

In the current implementation, this setting is used when the submission does not have its own delay.

Manual Form Indexing Lag (minutes)

API Log Retention Days

Defines the delay for URLs added through the form:

Google Indexing API > Import URLs

If the administrator manually pastes a list of URLs, each valid address will be scheduled with this delay.

It removes entries older than the number of days set in this field.

set0if manual imports should be added to the queue immediately,
Recommendation:15if you want to keep a buffer for deduplication and submission control.

Mass Action Indexing Lag (minutes)

API Log Retention Days

Defines the delay for URLs added by:

product mass actions,
CMS page mass actions,
indexing submission buttons on product, category, and CMS page edit screens.

It removes entries older than the number of days set in this field.

for bulk operations, leave the value15or higher,
for small stores and manual administrative work, you can consider a lower value.

Max Attempts

API Log Retention Days

Defines the maximum number of attempts to send a single queue record.

If Google returns a temporary error, the module will set the status toretryas long as the number of attempts is lower thanMax Attempts. After the limit is exceeded, the record will receive thefailed_permanent.

Errors treated as temporary:

408errors,
409errors,
412errors,
429errors,
500errors,
502errors,
503errors,
504.

Retry Delay (minutes)

API Log Retention Days

Base delay before the next send attempt after a temporary error.

Cron uses an increasing delay. The multiplier depends on the number of attempts and is capped at24. This prevents subsequent attempts from being made too aggressively.

Example for the value15:

Attempt	Approximate delay
1	15 minutes
2	30 minutes
3	60 minutes
4	120 minutes

Allowed Source Types

API Log Retention Days

manual,product,category,cms_page,amasty_blog_post

Comma-separated list of allowed source types.

Supported values:

Value	Meaning
`manual`	URL added manually through the import form.
`product`	Product URL.
`category`	Category URL.
`cms_page`	CMS page URL.
`amasty_blog_post`	Amasty Blog post URL if a separate integration module is used.

If the source type is not on the list, the scheduler will skip the submission and mark it asskipped.

It removes entries older than the number of days set in this field.

leave the default values if the store uses all standard sources,
remove sources that you do not want to allow into the queue.

Allowed URL Hosts

API Log Retention Days

puste

Comma-separated list of allowed URL hosts.

Example:

example.com,www.example.com

If the list is filled in, the module will accept only addresses belonging to the specified hosts. If a URL has a different host, validation will return the error:

host_not_allowed

It removes entries older than the number of days set in this field.

always fill in this list in production,
add all hosts used by the store, for example the main domain, thewwwversion, store view domains, and language domains,
do not add test domains to the production configuration.

Require HTTPS URLs

API Log Retention Days

Yes

Requires submitted URLs to use thehttps.

If the field is enabled, an address withhttp will be rejected with the error:

https_required

It removes entries older than the number of days set in this field.

for production stores, leaveYeserrors,
Nouse

only in exceptional test environments.

9. Auto-Indexing section

API Log Retention Days

No

Default:

The field is prepared for automatic integrations for saving or deleting entities and for additional URL providers.

It removes entries older than the number of days set in this field.

Recommendation:Noleave
if auto-indexing has not been implemented in the project,

enable it only when the project includes support for automatic entity events using this configuration.

10. Logs section

API Log Retention Days

Default:

Defines the number of days to keep API logs.

03:15

The log cleanup cron runs daily at:

It removes entries older than the number of days set in this field.

90Recommendation:
days is a reasonable diagnostic value,
with a large number of requests, you can reduce retention,

for SEO audits, you can increase retention, keeping the size of the log table in mind.

11. Installation and configuration assistant

Google Indexing API > Setup Assistant

The assistant is located in:

Its purpose is to quickly check whether the configuration on the Magento and Google side is ready for the first test.

11.1. Current Status section

Field	Meaning
`Module`	Meaning
`Dry Run`	Indicates whether the module is enabled in the configuration.
`Credentials`	Indicates whether test mode is active without actual sending to Google.
`Service Account Email`	Shows whether the module can read and parse Google credentials.`client_email`Displays the
`Allowed Hosts`	from the service account JSON. This address must be added as an owner in Search Console.
`Queue`	Shows the list of hosts allowed in the configuration.`scheduled`errors,`pending`errors,`retry`and`failed_permanent`.

, go back to the configuration and correct the JSON or credentials file.CredentialsIfMissing or invalidhas the status

, go back to the configuration and correct the JSON or credentials file.Allowed HostsIfNot configuredshows

, the module does not restrict hosts. Technically, this may work, but in production it is recommended to explicitly enter the store hosts.

11.2. Setup Steps section

The assistant displays a list of steps required before the first actual request:
Create or select a Google Cloud project.
Enable Indexing API and create a JSON key for the service account.
Paste the JSON or upload the JSON file in the Magento configuration.
Add the service account email as an owner in Google Search Console.Dry Run.

enabled.

The assistant includes links to:
Google Cloud for Indexing API,
module configuration in Magento,

Google Search Console.

11.3. Test Google Credentials

Test Google Credentials

Button:

https://www.googleapis.com/auth/indexing

checks whether Magento can use the service account data to obtain an OAuth token for the scope:

A positive result means that:
the JSON is valid,
the private key can be used,

Google issued an OAuth token.

A negative result may indicate:
invalid JSON,private_keyerrors,
,
a missing required field in the JSON,
a communication problem with Google,

use of a key that is not a service account key.

This test does not yet confirm that the service account has owner access to the domain in Search Console. For that, a URL metadata test or an actual test URL submission is required.

11.4. Test URL Metadata

Test URL Metadata

Form:

allows you to enter a public URL from an allowed host and perform a metadata request to Google Indexing API.

Before sending the request, the module:
normalizes the URL,
checks whether the URL is absolute,httpthehttpserrors,
scheme,Require HTTPS URLsrequireshttpserrors,
is enabled,Allowed URL Hostschecks

if they have been configured.

Possible results:	Meaning
Meaning	HTTP 2xx success
Google returned metadata for the URL.	HTTP 404
Often means that the URL has not yet had a previous successful submission through Indexing API. This does not necessarily mean incorrect configuration.	Validation error before the request
The URL does not meet the module requirements, for example incorrect host, missing HTTPS, or a non-absolute address.	HTTP error other than 404

Check the Google message, Search Console permissions, credentials, and limits.

The metadata test does not create a new publish submission. It is used to diagnose the connection and URL status.

12. First launch step by step

Recommended first launch sequence:setup:upgrade.
.Stores > Configuration > Kowal > Google Indexing API.
.Enable = Yes.
.Dry Run = Yes.
.
Select the credentials source.
value from the JSON.Google Cloud Project IDFill inproject_idfrom the JSON.
value from the JSON.Allowed URL HostsFill inexample.com,www.example.com.
.
Leave the default limits if Google has not approved higher limits.
for a public URL from an allowed host.Google Indexing API > Setup Assistant.
.
Check whether the assistant shows credentials as ready.Test Google Credentials.
.
Add the service account email as an owner in Google Search Console if this has not been done yet.Test URL MetadataRun
for a public URL from an allowed host.Google Indexing API > Import URLs.
.URL_UPDATED.
.

bin/magento cron:run

19. .Google Indexing API > Indexing Queue.

20. .Google Indexing API > API Logs.

21. .Dry Run.

22. .

Add one test URL again and check the actual Google response.

13. Importing URLs from the admin panel

Google Indexing API > Import URLs

Manual import is located in:

Field	Field
`Action`	Description
`Store View`	Type of submission to Google: add/update or delete.`Use global/no store`.
`URLs`	is also available.

List of absolute URLs, one address per line.

Available actions:	Form action	Meaning
`Submit URLs for indexing`	`URL_UPDATED`	Meaning
`Delete URLs from indexing`	`URL_DELETED`	Informs Google that the URL has been added or updated.

Informs Google that the URL has been removed and may be removed from the index.

After submitting the form, the module will show a summary:
added,
updated,
deduplicated,
invalid,

skipped.

The first 10 validation messages are shown as a notice in the admin panel.

14. Indexing queue

Google Indexing API > Indexing Queue

The queue is located in:

Each queue record includes, among others:
URL,
store ID,
store ID,
website ID,
source type,
source entity ID,
request origin,URL_UPDATEDtheURL_DELETEDerrors,
action,
status,
priority,
number of attempts,
maximum number of attempts,
scheduled send date,
processing date,
last error code,
last error reason,
Google response,
Google response,created_by.

Queue statuses

Status	Meaning
`scheduled`	The URL is scheduled but is still waiting for the`scheduled_at`.
`pending`	The URL is ready to be processed by cron.
`processing`	The URL is currently being processed.
`success`	Google returned a success response.
`retry`	A temporary error occurred and the record is waiting for another attempt.
`failed_permanent`	Sending failed permanently or the maximum number of attempts was exceeded.
`cancelled`	The record was manually canceled.

Actions on queue records

Action	Operation
`Transmit Now`	Marks the record as urgent, locks it, sends it immediately through the Google client, and saves the result.
`Retry`	Sets the record to`pending`, clears the lock, and schedules a retry immediately.
`Cancel`	Sets the status to`cancelled`and clears the lock.

Note:Transmit Nowperforms an actual request ifDry Run = No. WithDry Run = Yes, a dry-run log will be saved without actual sending to Google.

15. Cron

The module adds two cron jobs in thedefault.

Queue processing

kowal_google_indexing_process_queue

Schedule:

*/5 * * * *

The job runs the queue processor every 5 minutes.

The processor:

Checks whether the module is enabled.
Releases old locks onprocessingrecords older than 30 minutes.
Movesscheduledrecords topendingifscheduled_at <= now.
Checks available slots in the daily and per-minute limits.
Fetchespendingandretry.
Sorts them by priority and scheduled send date.
Sends the request to Google or performs a dry-run.
Saves the response, status, and API log.

Log cleanup

kowal_google_indexing_cleanup_logs

Schedule:

15 3 * * *

The job removes API logs older than the number of days set in the field:

API Log Retention Days

16. API logs

Logs are available in:

Google Indexing API > API Logs

The log includes:

queue record ID,
store ID,
request type,
endpoint URL,
payload,
HTTP status,
response body,
request duration,
log creation date.

Request types:

Type	Meaning
`publish`	Actual URL submission to Google.
`publish_dry_run`	Processing in dry-run mode without an actual request to Google.
`metadata`	Metadata test for a URL.

17. Mass Actions and admin buttons

The module adds mechanisms for submitting URLs from the admin panel.

Products

A mass action is available on the product grid to add product URLs to the queue.

The module skips products that are:

disabled,
not individually visible.

URLs are generated based on URL rewrites for active store views.

CMS pages

A mass action is available on the CMS page grid to add page URLs to the queue.

The module skips inactive pages.

If a CMS page is assigned to all store views, the module resolves URLs for all store views.

Product, category, and CMS page - buttons on the edit form

The module adds indexing submission buttons on edit screens for:

product,
category,
CMS page.

The button resolves entity URLs for store views and adds them to the queue asURL_UPDATED.

18. Recommended initial configuration

For the first production implementation:

Field	Recommendation
`Enable`	`Yes`after saving credentials and allowed hosts.
`Dry Run`	`Yes`during testing, later`No`.
`Credentials Source`	`Encrypted configuration value`or`Uploaded JSON file`, according to the project policy.
`Google Cloud Project ID`	`project_id`from the JSON.
`Daily Publish Limit`	`200`, unless Google has approved a higher limit.
`Requests Per Minute Limit`	`60`or less for a cautious implementation.
`Cron Batch Size`	`20`.
`Default Indexing Lag`	`15`.
`Manual Form Indexing Lag`	`0-15`, depending on the administrators' workflow.
`Mass Action Indexing Lag`	`15`.
`Max Attempts`	`5`.
`Retry Delay`	`15`.
`Allowed Source Types`	`manual,product,category,cms_page,amasty_blog_post`.
`Allowed URL Hosts`	All production store hosts.
`Require HTTPS URLs`	`Yes`.
`Enable Auto-Indexing`	`No`, unless the project implements automatic providers.
`API Log Retention Days`	`90`.

19. Common issues and diagnostics

Credentials test failed

Check:

whether the JSON is valid,
whether the JSON comes from a service account,
whether it containsprivate_keyandclient_emailerrors,
whether thetypefield has the valueservice_accounterrors,
whether the JSON file was not damaged during pasting.

Google returns a permission error

Check:

whether the domain is verified in Search Console,
whetherclient_emailis added as an owner,
whether the tested URL belongs to the same Search Console property,
whether you are using the correct Google Cloud project and the correct JSON.

URL is rejected before sending

Check the validation message:

Message	Cause
`empty_url`	Empty URL.
`url_too_long`	The URL has more than 2048 characters.
`url_not_absolute`	The URL has no scheme or host.
`https_required`	The HTTPS requirement is enabled, and the URL uses HTTP.
`invalid_scheme`	The scheme is neither`http`nor`https`.
`host_not_allowed`	The URL host is not in`Allowed URL Hosts`.

The queue is not processing

Check:

whetherEnable = Yeserrors,
whether Magento cron is running,
whether records have thependingorretryerrors,
whetherscheduled_atis not in the future,
whether the daily or per-minute limits are not used up,
whetherDaily Publish LimitandRequests Per Minute Limitare not set to0.

Records go to`retry`

Check:

HTTP status in the queue record,
API log,
Google response,
whether the429errors,
whether there are temporary5xxerrors,
whetherMax AttemptsandRetry Delayare set as expected.

20. Optional integration with Amasty Blog

Integration with Amasty Blog is provided as a separate module:

Kowal_GoogleIndexingApiAmastyBlog

Package:

kowal/module-google-indexing-api-amasty-blog

This module is not required for the main integration to work. It should be installed only in projects that useamasty/blog and need a mass action for blog posts.

Purchase information	DEMO BACKEND username: indexing hasło: M2Indexing
Theme compatibility	Luma / Blank, KOWAL

Google Indexing API for Magento 2

Description / Google Indexing API for Magento 2

Manage URL submissions in one Magento queue.

How does your store benefit?

Notify Google faster about store changes

Better control over address submissions

Less manual work after store changes

Safer use of API limits

Fewer duplicates and repeated submissions

More transparency for the team

Easier troubleshooting

Ready for store growth

How the module works in practice

Main features

Who this module is for

New or changed products

Updating CMS pages and landing pages

Managing addresses after site changes

Bulk SEO actions

Business impact

Official Google Indexing API scope

Setup assistant and initial launch

Amasty Blog integration and new sources

Installation via Composer

From configuration to results

Control the submission process

Organize submissions and API diagnostics

More Information

DEMO

Module Installation Instructions

Google Indexing API for Magento 2 - installation and configuration

1. Important information before implementation

2. Requirements

3. Module installation

3.1. Installation via Composer

3.2. Local installation inapp/code

3.3. Verifying the installation

4. Preparing Google Cloud and Search Console

4.1. Creating a Google Cloud project

4.2. Creating a service account

4.3. Adding the service account as an owner in Search Console

5. Module configuration in Magento

6. General section

Enable

Dry Run

7. Google Access Credentials section

Credentials Source

Service Account JSON

Service Account JSON File

Google Cloud Project ID

8. Queue and Limits section

Daily Publish Limit

Requests Per Minute Limit

Cron Batch Size

Default Indexing Lag (minutes)

Manual Form Indexing Lag (minutes)

Mass Action Indexing Lag (minutes)

Max Attempts

Retry Delay (minutes)

Allowed Source Types

Allowed URL Hosts

Require HTTPS URLs

only in exceptional test environments.

9. Auto-Indexing section

enable it only when the project includes support for automatic entity events using this configuration.

10. Logs section

for SEO audits, you can increase retention, keeping the size of the log table in mind.

Its purpose is to quickly check whether the configuration on the Magento and Google side is ready for the first test.

, the module does not restrict hosts. Technically, this may work, but in production it is recommended to explicitly enter the store hosts.

Google Search Console.

This test does not yet confirm that the service account has owner access to the domain in Search Console. For that, a URL metadata test or an actual test URL submission is required.

The metadata test does not create a new publish submission. It is used to diagnose the connection and URL status.

Add one test URL again and check the actual Google response.

The first 10 validation messages are shown as a notice in the admin panel.

Queue statuses

Actions on queue records

15. Cron

Queue processing

Log cleanup

16. API logs

3.2. Local installation in`app/code`

Records go to`retry`