Imagify WordPress seven-stage workflow from media inventory and backup through API connection, optimization, WebP or AVIF verification, and restore

Imagify WordPress Optimization and API Troubleshooting Checklist

Written and reviewed by Arifur Rahman · Last reviewed July 29, 2026

A successful Imagify setup has three separate results: WordPress completes the optimization, the expected WebP or AVIF file exists, and the visitor's browser actually receives that next-generation image without a layout or cache regression. This guide gives WordPress site owners a controlled way to estimate quota, protect originals, connect their own Imagify account, choose settings, test a small image set, verify delivery, diagnose API or server errors, and retain a safe restore path.

Account and privacy boundary

Use the site owner's authorized Imagify account, plan, API key, and quota

This article assumes that the WordPress owner controls an active Imagify account or has documented permission to configure the purchaser's account on the named site. The phrase Imagify Pro is common in searches and older commercial listings, but Imagify's public pricing page currently names its plans Starter, Growth, and Infinite. The live account and current official documentation are the authority for plan status, quota, billing, upload limits, support, and available features.

eArif does not provide an Imagify license, API key, account, subscription, quota, site allocation, entitlement, or official vendor support through this article. The guide does not validate a marketplace seller, transfer a subscription, bypass a quota, or establish that a third party may distribute account access. The existing eArif legacy commercial result is a separate URL under review and is not the conversion destination for this informational guide.

Treat the API key as a secret. Do not put it in a contact form, analytics event, public ticket, screenshot, source repository, browser recording, or handoff document. Imagify documents wp-config.php constants and subaccounts as ways to reduce key exposure, but any access method still needs owner approval and appropriate server controls. For a first diagnosis, a public page URL, WordPress and Imagify versions, environment role, selected settings, redacted error, image URL, response content type, and timestamp are normally more useful than the key itself. Review the eArif privacy boundary before sharing implementation evidence.

Continue self-service

You control the authorized account and site, know the quota and image scope, have recoverable originals, and can test a small noncritical batch.

Pause for the account owner

The API key source, plan, billing, quota ownership, multiple-site use, or permission to create a subaccount is unclear.

Escalate the implementation

The issue crosses hosting, CDN, Cloudflare, cache, theme output, responsive images, a migration, or a live customer and revenue path.

Know what owns each result

The account, originals, WordPress sizes, Imagify settings, delivery layer, and browser prove different things

An optimized status in WordPress is not the same as a next-generation file existing, and neither proves that the browser received it. Likewise, an API error may belong to the key, account, outbound server connection, firewall, or timeout rather than the image itself. Keep these dependencies separate so one visible symptom does not trigger several unmeasured changes.

Dependency What it controls Evidence to inspect Common wrong assumption
Authorized Imagify account Current API key, plan, monthly allowance, usage, subaccounts, billing, and vendor support. The owner can access the account and confirm current status without publishing the key. A key copied from an old site proves that the account, quota, and permission are current.
Original images and recovery Restore, re-optimization, new thumbnail generation, and future WebP or AVIF creation. Site backup, Imagify backup setting, original-file location, disk capacity, and a tested restore sample. An optimized file can always be converted back into the exact original later.
WordPress media inventory Original uploads, registered thumbnail sizes, custom folders, image dimensions, and the volume sent for processing. Tools > Site Health > Info, uploads size, selected thumbnail sizes, theme behavior, and sample media records. One Media Library row equals one file and one unit of quota.
Imagify plugin settings Compression level, resize ceiling, auto-optimization, backups, selected files, next-generation creation, and display method. A dated settings record plus the result for a small representative image set. The vendor's recommended defaults fit every theme, CDN, image type, and visual-quality requirement.
Host and request path Outbound API communication, timeouts, memory, file writes, rewrite rules, scheduled work, and security filtering. Site Health, server and security logs, failed request time, permissions, web server, and current allowlist evidence. An invalid-key message can only be caused by typing the wrong key.
Theme, CDN, Cloudflare, and cache HTML or rewrite delivery, external image hosts, responsive variants, CSS backgrounds, cached content, and edge behavior. Rendered markup, final image hostname, cache state, CDN rules, public response headers, and representative layouts. Creating WebP or AVIF automatically changes every public image response.
Visitor browser The final URL, content type, transfer size, dimensions, visual result, fallback, and page behavior. Network panel, page source when relevant, desktop and mobile screenshots, and a cache-controlled retest. A filename ending in .jpg proves that the browser received JPEG rather than a rewritten WebP response.

Estimate before processing

Imagify quota depends on source bytes, generated sizes, re-optimization, and every site sharing the account

Start with the uploads directory size and the site's registered image sizes, not the Media Library item count alone. Imagify states that the original and each selected thumbnail contribute to processing and that quota is deducted from the original size of each file sent. A single upload can therefore produce many processed files. Re-optimizing at another compression level consumes quota again. Restoring an original does not consume quota, but it also does not refund quota already used; failed images do not consume it.

One API key can be used across multiple sites under Imagify's current documentation, but those sites share the account's quota. That means a bulk job on one installation can affect the remaining allowance for another. Subaccounts may create cleaner key and quota boundaries for client sites. The account owner should make that decision; do not assume that unlimited websites means unlimited monthly processing.

Current public plan Published allowance reviewed July 29, 2026 Planning implication
Starter $0 per month, 20 MB per month, approximately 200 images, unlimited websites, and a 2 MB maximum upload. Use a measured pilot. The approximate image count is not a promise for a library with large originals or many registered sizes.
Growth $5.99 monthly or $4.99 per month billed yearly, 500 MB per month, approximately 5,000 images, unlimited websites, and $5 per additional GB. Compare uploads size, monthly additions, thumbnails, other connected sites, and re-optimization risk before relying on the approximate count.
Infinite $11.99 monthly or $9.99 per month billed yearly, with unlimited images, websites, and upload size on the reviewed pricing page. Unlimited plan language does not remove the need for backups, representative QA, server capacity, delivery verification, or owner-approved account use.

Pricing, taxes, limits, and plan names can change. Recheck the official pricing page and the live account before purchase or renewal. A safer rollout estimate records uploads size, selected thumbnail sizes, custom folders, current allowance, other sites using the key, monthly upload volume, pilot consumption, and a reserve for retries. It does not multiply an advertised average by the Media Library count and call that exact.

Seven-stage workflow

Move from inventory to a verified public response before expanding the batch

Each stage creates evidence for the next. Use one representative JPEG or PNG, its generated sizes, and pages that expose the site's important rendering paths. A useful pilot includes a prominent content image, a responsive thumbnail, and any special case such as a CSS background, page-builder image, external CDN URL, or dynamically loaded element.

  1. 1Inventory
  2. 2Backup
  3. 3Connect API
  4. 4Choose settings
  5. 5Optimize
  6. 6Verify WebP or AVIF
  7. 7Restore and hand off
Crawlable equivalent of the article visual: inventory the media and delivery path, preserve a restorable site and original-image backup, connect the owner's private API key, choose compression, resize, file, and next-generation settings, optimize a controlled pilot, verify both file creation and browser delivery, then expand or restore with a dated handoff. API, quota, format, cache, layout, and restore symptoms route back to the earliest dependency that can own the result.
  1. Inventory files, sizes, paths, and baseline pages. Record WordPress, Imagify, theme, page builder, web server, CDN or Cloudflare, cache, uploads size, custom folders, registered thumbnail sizes, monthly image volume, and current plan allowance. Save the public image URL, response content type, dimensions, transfer size, and appearance for representative pages before changing anything.
  2. Create recovery at both site and image level. Make a current restorable site backup and confirm who can restore it. Enable Backup original images before the pilot, verify available disk space, and prove that one sample original can be located. Do not delete original backups merely to reduce storage before the team decides how it will restore, re-optimize, or generate future formats.
  3. Connect the authorized account privately. Have the owner retrieve the current API key from the Imagify account and enter it under Settings > Imagify or use an owner-approved protected method. Do not copy it into the work record. If validation fails, preserve the redacted message and time before regenerating keys, disabling security, or changing several server controls.
  4. Choose settings from actual display and recovery needs. Decide Smart versus Lossless, automatic upload optimization, maximum resize width, original backup, selected thumbnail sizes, custom folders, WebP versus AVIF, and picture-tag versus rewrite delivery. Record why each nondefault choice exists and which page proves it.
  5. Run a representative pilot and measure the account result. Optimize a small set that covers the main image patterns. Record status, before and after bytes, visual appearance, generated sizes, next-generation creation, quota before and after, errors, and time. Stop at the first unexplained failure instead of launching Bulk Optimization repeatedly.
  6. Prove the public browser response. Confirm next-generation creation in the Media Library, then test the public page. Picture-tag delivery can be checked in rendered markup or source where applicable. Rewrite delivery may keep the original filename in markup, so inspect the browser network response and content type. Test cache-warm and cache-bypassed states, important responsive widths, CSS backgrounds, lazy-loaded elements, external images, and fallback behavior.
  7. Expand, hold, or restore with accountable evidence. Expand the batch only when the representative pages pass. If image quality, layout, delivery, quota, or server behavior fails, restore the affected sample where an original exists and route the root cause. Handoff the account owner, site, environment, versions, settings, processed scope, quota observation, pages tested, exceptions, recovery route, and next review without including the API key.

Settings are release decisions

Choose each Imagify setting by the failure it must prevent and the evidence that will accept it

Setting Practical default Change it when Acceptance evidence
Smart or Lossless compression Start a pilot with Smart, Imagify's current default. A brand, product, artwork, medical, legal, or other pixel-sensitive image has an approved visual-quality requirement. Side-by-side review at intended display sizes plus measured file results; re-optimization cost is understood.
Auto-optimize on upload Enable after the pilot for a stable upload path. The site has selective assets, unusual generated images, a controlled editorial gate, or unresolved errors. A new test upload generates the expected sizes and formats without blocking or changing the publishing path.
Backup original images Enable and budget disk space. Disable only after an owner-approved external-original policy and tested recovery path replace its restore functions. One optimized sample can be restored; original storage and retention have named owners.
Resize larger images Set a ceiling based on the largest real display need. Zoom, retina, print, source download, product detail, or future reuse requires larger dimensions. Representative desktop and mobile displays remain sharp, and the retained original covers approved future use.
Thumbnail sizes and custom folders Enable sizes and folders proven to appear publicly. A registered size is unused, another folder serves real images, or the theme changes its responsive output. Rendered pages request the selected files; exclusions have no public or operational dependency.
WebP or AVIF creation Choose one current next-generation format for the pilot. Compatibility, file size, image quality, CDN behavior, or the site's format strategy supports another choice. The expected variant exists for the original and required thumbnails, with JPG or PNG fallback available.
Picture tags or rewrite rules Choose from the real server, CDN, Cloudflare, HTML, CSS background, and dynamic-loading path. Picture markup causes layout gaps or misses late-loaded and background images, or rewrite rules cannot control an external CDN. The browser receives the intended format across representative pages and widths without visual or fallback regression.

Troubleshoot the first failed boundary

Match each Imagify symptom to evidence that can separate account, server, file, and delivery causes

Visible symptom First evidence checks Safe next action Avoid
The API key is not valid Owner-confirmed current key, exact redacted message, timestamp, app.imagify.io reachability, current vendor addresses, host, firewall, security plugin, and outbound logs. Correct the proven key or communication failure, then validate once. Ask the owner or Imagify when account state is unclear. Posting the key, repeatedly regenerating it, or broadly disabling production security.
Optimization stays at 0% or stops First failed image, HTTP or cURL error, PHP memory and timeout evidence, scheduled requests, file permissions, Imagify Tools result, and server logs. Give the host or vendor the redacted failure and time; test one corrected dependency on a sample. Running the full bulk job again, adding arbitrary server values, or changing memory, cache, firewall, and plugins together.
Quota falls faster than expected Original bytes, selected thumbnail count, custom folders, re-optimization attempts, other sites on the key, and before/after account usage. Recalculate from the processed pilot and disable only proven-unused sizes before continuing. Using the Media Library row count or advertised average image count as an exact allowance.
WebP or AVIF says generated but is not displayed Display setting, picture versus rewrite method, rendered markup, network content type, server, CDN or Cloudflare, external hostname, cache, and generated file existence. Fix the first delivery-layer mismatch and retest the same URL with controlled cache state. Regenerating every image before proving whether creation or display failed.
Images shift, disappear, or look wrong Picture markup, CSS, intrinsic dimensions, responsive sources, lazy loading, builder output, crop, compression choice, browser, and pre-change screenshot. Hold rollout, restore the sample where possible, and isolate markup, style, sizing, or quality as a separate defect. Clearing all evidence, treating smaller bytes as acceptance, or fixing layout with unreviewed global CSS.
Some images never use a next-generation format CSS background, external CDN, late JavaScript insertion, missing generated size, custom folder selection, Nginx or Apache rules, and actual request URL. Choose a delivery method that can reach that image path or let the CDN own conversion with a documented boundary. Assuming every img, background, remote file, and generated component shares one delivery path.
Restore or re-optimize is unavailable Original backup setting at processing time, expected backup folder, migration or restore history, exact filename and subfolder, and external originals. Recover the correct original into the documented location or use the site backup; ask the owner before replacing files. Calling an already optimized copy the original or deleting remaining backups to save space.
Images are smaller but page metrics do not improve Which image owns the measured view, response bytes, dimensions, priority, layout stability, caching, server response, scripts, fonts, test variance, and field data. Treat image optimization as one measured dependency and diagnose the actual performance bottleneck separately. Promising a PageSpeed, Core Web Vitals, search, traffic, or conversion result from plugin activation alone.

Optimization is not release acceptance

Verify image quality, delivery, layout, quota, and recovery before a full-library rollout

Verification area Minimum check Failure owner
Account and quota The authorized account is connected, pilot usage is explainable, and other connected sites retain their expected allowance. Account owner, plan, shared key, selected sizes, processed bytes, or re-optimization history.
File and original The optimized file and required variants exist, retain acceptable quality and dimensions, and have a recoverable original. Source image, settings, file write, selected thumbnail, custom folder, backup, or migration.
Public delivery The browser receives the intended WebP, AVIF, or fallback response for selected images with cold and warm cache evidence. Display setting, HTML, rewrite rule, web server, CDN, Cloudflare, cache, external host, or browser support.
Visual and responsive behavior Prominent images, thumbnails, backgrounds, lazy-loaded content, page-builder output, and selected desktop and mobile layouts match the approved baseline. Compression, crop, source set, dimensions, CSS, JavaScript, theme, builder, or delivery method.
Performance interpretation Image bytes and delivery are measured separately from server, script, font, layout, and test-variance effects. The actual bottleneck identified by browser and field evidence, not the plugin status alone.
Recovery and handoff Processed scope, settings, exceptions, original location, restore owner, account owner, remaining risk, and next review are documented without secrets. Site owner, account owner, implementer, host, CDN, vendor, or maintenance owner.

Interactive working review

Imagify WordPress optimization checklist: 28 local checks

Complete these checks in sequence. The checklist saves only checked item IDs in this browser's local storage. It does not send a domain, API key, account, quota, private URL, customer information, or image file to eArif.com. Reset it before leaving a shared device.

0 of 28 checks complete

0 of 28

Hold: the Imagify review is incomplete.

01Authorization and inventory
02Recovery and baseline
03Account and quota
04Settings decision
05Controlled optimization
06Public delivery QA
07Release and handoff

Choose by evidence owner

Self-service, Imagify support, hosting support, Systems Audit, and Contact solve different problems

Situation Best next route Reason
Authorized account, known quota, recoverable originals, healthy pilot Complete this checklist directly and expand in controlled batches. The account, files, settings, delivery, acceptance, and recovery owners are available.
Plan, billing, quota, account, API key, or vendor behavior is disputed Use the account owner and official Imagify support. Only the account authority and vendor can resolve subscription and account-side evidence.
Outbound requests, timeouts, memory, file writes, or firewall blocks fail Give the host or security owner the redacted request, timestamp, status, and current official connection requirements. The first failed boundary is server communication or execution rather than an image-setting decision.
The issue crosses WordPress, theme, CDN, Cloudflare, cache, migration, or important customer pages Start with Systems Audit. The result depends on several owners and needs a map, evidence baseline, controlled QA, recovery path, and handoff.
The correct owner or work scope is still unclear Contact Arif with privacy-safe evidence. A public URL, versions, environment, selected settings, redacted symptom, image path, content type, and stopping point are enough for initial routing.

Before requesting work, review eArif's proof boundaries, WordPress software context, and Arifur Rahman's implementation focus. Do not submit an API key, account login, private staging credential, database export, customer image, or private server log through the contact form.

If the browser receives the expected image file and content type but the failure appears only inside a Bricks template or responsive layout, use the Bricks Builder activation and rendering checklist so image delivery and builder rendering are diagnosed as separate owners.

Frequently asked questions

Imagify WordPress setup and troubleshooting questions

Is Imagify Pro still the name of a current plan?

Imagify Pro is a common search phrase and appears in older or third-party listings, but Imagify's public pricing page reviewed July 29, 2026 names the plans Starter, Growth, and Infinite. Check the live official pricing page and the owner's account before relying on an old plan name, price, allowance, or reseller description.

Why does Imagify say my API key is not valid?

First have the account owner confirm the current private key. If it is correct, Imagify says to check whether the host, server, security plugin, or firewall blocks communication with app.imagify.io or its current service addresses. Preserve the redacted message and timestamp, then test one proven correction without publishing the key or broadly disabling security.

Why are Imagify WebP or AVIF images generated but not served?

Creation and display are separate settings and delivery steps. Check the display option, picture-tag or rewrite method, actual image hostname, server type, CDN or Cloudflare behavior, cache, CSS backgrounds, late-loaded images, and browser network content type. Rewrite delivery can serve WebP or AVIF while the HTML still shows the original filename.

How does Imagify calculate quota on WordPress?

Imagify states that the original and every selected thumbnail contribute to processing, with usage based on the original bytes of each file sent. Re-optimizing consumes quota again. Restoring does not consume quota or return prior usage, and failed images do not consume it. Sites sharing one account or key also share its quota.

Can one Imagify API key be used on multiple WordPress sites?

Imagify currently documents use on multiple websites, but the account's quota is shared. It recommends subaccounts when separate keys or quota allocation are useful and states that its service cannot be bundled with hosting packages. Account ownership, client permission, key privacy, quota responsibility, and current terms still need explicit decisions.

Can I restore original images after Imagify optimization?

Yes, when the original backup exists. Imagify requires original backups for its normal restore path and also uses originals for re-optimization, new thumbnail sizes, and future next-generation formats. Restoring does not refund consumed quota. Verify one sample restore and retain an independent site backup before processing the full library.

Primary sources reviewed July 29, 2026

Official Imagify and WordPress sources used for this guide

Plugin interfaces, service addresses, account rules, plan names, prices, allowances, browser support, and delivery recommendations can change. Recheck these primary sources, the live Imagify account, the current plugin release, and the site's actual network responses before acting on an old screenshot, reseller page, cached answer, forum post, or AI summary.

Back to blog