Begin with why the image is on the page
An image should help a visitor understand the article, recognise a service or complete a task. Search engines can also use relevant images to interpret and present a page, but the starting point is still the reader's purpose. A decorative gradient, an original illustration of a DNS process and a screenshot of account settings serve very different functions. Optimisation means giving each the correct treatment rather than adding keywords to every visual simply because it appears in a content-management system.
For an OnHypp article explaining business email, an illustration of an envelope or domain-based message can reinforce the subject. A technical screenshot may need a caption or explanation so that someone can follow the steps. A company logo serves brand recognition rather than explaining email protocols. Before uploading, record who owns the asset, whether its use is permitted and whether it is genuinely relevant to the surrounding content. An unrelated high-resolution picture adds page weight without reliably helping a customer.
Choose understandable descriptive file names
Google's image guidance says short descriptive file names can provide a modest clue about an image's subject. A name such as professional-email-domain-setup.svg communicates more than IMG_8422.png. That does not mean a file name alone will cause a high ranking, nor should it contain every related keyword. Use readable words, a stable naming convention and an extension that matches the actual media format. Avoid renaming approved brand originals casually if existing links or customer documents already depend on those filenames.
Include a reasonable topic identifier when an illustration belongs to one article, especially in a larger content library. Do not create hundreds of differently named copies of exactly the same generic graphic just to increase sitemap entries. For a bilingual page, one genuinely language-neutral illustration may be used on both URLs with correct translated alt text; localized graphics containing visible words may require separate assets. Keep paths stable where possible because frequent arbitrary renaming forces search engines and browser caches to relearn the resource.
Understand the purpose of alternative text
The HTML alt attribute provides a text alternative when an image cannot be seen or loaded. Screen-reader users rely on it to understand informative images and the purpose of functional images. Google's guidance also uses alt text alongside page content and computer vision to interpret imagery. Write the alternative for the information or function the image provides, not as an advertising slogan. A short, accurate description is generally more useful than a long string of loosely related keywords.
Consider an informative illustration showing an invoice travelling from a laptop through an email server to a customer. An alt might explain the route in plain language. If the same image exists only as visual decoration beside a fully explanatory heading, an empty alt may be more appropriate. W3C's Web Accessibility Initiative distinguishes informative, decorative and functional images; the correct choice depends on context, not the image file type. This judgment should be part of content editing rather than left to an automatic file-name generator.
Use empty alt for images that are purely decorative
A decorative background shape or flourish may not add information a screen-reader user needs. Repeating an irrelevant description of every border, glow and abstract shape can overwhelm the main content. W3C recommends alt="" for decorative images so assistive technology can generally skip them. This is different from leaving off the alt attribute, which may cause some screen readers to announce the file name or URL instead. Proper decoration handling can improve navigation clarity.
However, an image that conveys meaning is not decorative merely because it is attractive. A chart explaining a comparison, a product photo showing dimensions or a screenshot of a critical error needs a suitable alternative. Sometimes a short alt alone cannot carry the detail; use nearby explanatory text, a data table or a longer description as needed. Do not set alt empty on every image to make an accessibility checker quiet. The content editor must decide what information would be lost if the picture disappeared.
Give linked logos a functional description
When a website logo is the only content of a link that returns a visitor to the homepage, the function of the link is important. W3C's functional-image guidance suggests alternative text that communicates the link destination or action, such as the organisation name with a homepage context, rather than describing decorative properties of the logo. If the link already has an accessible text label, avoid creating redundant announcements. Test the resulting accessible name, not simply whether the alt field is non-empty.
Brand identity is also a matter of using the approved original. Preserve proportions, colours and recognisable elements instead of substituting an unapproved icon. The website header and favicon often use different approved variants because a wide wordmark is not legible inside a tiny square. Keep their purposes distinct. Google's Organization logo structured data refers to the representative brand image; a favicon link points to the icon used in certain search and browser contexts. A visually consistent set of assets helps recognition but cannot force an immediate search-engine display.
Put visuals near the content they explain
Google recommends placing images near relevant text and using useful page titles and captions. An illustration of email authentication belongs near the section explaining SPF, DKIM and DMARC, not beside unrelated web hosting pricing. A screenshot of a domain provider's settings should be accompanied by a note that interfaces may change. This surrounding context helps both visitors and automated systems distinguish the purpose of the graphic. Alt text cannot correct a page whose subject and image are fundamentally mismatched.
On article pages, a representative cover image can set context, while diagrams embedded beside individual steps can explain more specialised details. Give each figure an appropriate heading or caption when it adds meaning. Avoid putting all original diagrams only inside homepage cards if users need to see them on the actual article. Keep images inside normal HTML img elements where feasible so search engines can find their src values. CSS-only background images may be aesthetically useful but are not a dependable discovery method for content images.
Select formats for the actual visual
Photographs, interface screenshots and vector illustrations behave differently when compressed. JPEG or WebP may be suitable for many photographic assets; PNG can preserve crisp interface detail or transparency; SVG can remain sharp for line-based illustrations when the file is safe and properly authored. Google supports several common image formats, including PNG, JPEG, WebP, SVG and AVIF, but not every browser or workflow has identical constraints. Choose a practical format and match the extension to the real file type.
An oversized photo can slow a mobile page, while excessively compressed text inside a screenshot can become unreadable. Start with the actual display dimensions, then generate a suitable quality version without destroying essential details. SVG illustrations should not contain unnecessary scripts or unsafe embedded content; review their source when files come from outside suppliers. Preserve source originals separately for legitimate future editing, but publish only the assets needed by the customer-facing site. File size optimisation must not mean illegible diagrams.
Support responsive layouts instead of fixed-width imagery
People view small-business websites on phones, tablets and desktop screens. Images should scale within their containers without overflowing or hiding essential content. HTML srcset and picture elements can offer different versions for responsive needs, while a normal img src provides a useful fallback for crawlers and browsers. Google specifically recommends retaining a src attribute. Do not rely exclusively on CSS background images or a custom script that never exposes a normal image URL.
Test at narrow widths and with browser zoom. A complex flowchart that looks fine on a large monitor may require a simpler mobile version or an accessible text explanation. Check that text in the image remains readable and that interactive controls near it are not covered. A logo should preserve its proportions, while a photographic cover may be cropped appropriately if no essential information is removed. Responsive behaviour is a usability requirement, not proof of search ranking.
Use image sitemaps for additional discovery
Google supports an image sitemap extension within a normal XML sitemap. An image:image element can associate an image:loc URL with the page on which the asset is relevant. This is particularly useful when a site's images might otherwise be difficult to discover. Still, an image sitemap is an optional supporting signal; it does not replace embedding the actual visual in the page or ensuring its file can be fetched. An XML entry pointing to a nonexistent file is not useful.
Associate each article illustration with the correct article's canonical English and Bahasa Melayu URLs where appropriate, rather than adding every image to every page. A logo can also be associated with homepages as a discovery hint while Organization JSON-LD supplies the clearer identity relation. Keep XML namespaces and URLs correct. Run checks that the referenced paths exist in the static assets and return image responses after deployment. Do not claim that Google has indexed an image merely because the XML parses successfully.
Know what Open Graph and Article schema contribute
An article's Open Graph image metadata supplies a preferred preview for many social and messaging contexts, while schema.org Article markup can describe a representative image to search systems. Google's image guidance explains that preferred previews can be influenced by relevant structured data and og:image, but their selection is automated. Choose an illustration that genuinely represents the page rather than always using a company logo. An image with an extreme aspect ratio or lots of small text may make a poor preview.
Keep absolute public asset URLs consistent across the HTML, structured data and sitemap. If a site uses a content delivery network, account for public reachability and ownership verification where required. Do not invent a publication date in Article schema because a draft was committed on GitHub. Use actual source-specific data and real post-release dates when available. Metadata should agree with visible content. A discrepancy between the article's topic and its preview image can confuse readers and reduce trust.
Protect loading speed without hiding important content
Large images can dominate page transfer size, especially on mobile networks. Optimising dimensions, compression and loading strategy helps visitors reach the text sooner. Lazy loading may be appropriate for images far below the initial viewport, but a hero image critical to the first visible screen may deserve different priority. Use native browser attributes where practical and verify that images still appear when scripts are delayed. Performance techniques should not accidentally prevent Google or assistive technologies from encountering useful assets.
Measure the actual page rather than assuming every new format is automatically faster. Test a representative mobile connection, image clarity and layout stability. Provide intrinsic dimensions or appropriate styling so the page does not jump as media loads. Do not replace an approved brand logo with a tiny low-quality derivative merely to improve a speed metric. Any optimisation should preserve visual identity and meaning while reducing unnecessary bytes. After deployment, repeat the check on the public site.
Apply a consistent bilingual accessibility review
Alternative text should match the page's language and context. An English technical article and its Bahasa Melayu counterpart can show the same original illustration, but users of each page should receive understandable text in the correct language. Translation should preserve technical meaning rather than blindly translating product names or protocol acronyms. Read the alt aloud and ask whether someone could understand the essential purpose without seeing the picture. Keep descriptions concise and avoid stuffing repeated sales keywords into both versions.
Also check captions, visible text embedded in graphics and functional icons. If an image includes English-only instructions on the Malay page, either provide an appropriate translation nearby or consider a localized graphic when those instructions are essential. Verify colour contrast where text overlays photos and ensure status is not communicated by colour alone. Accessibility is an ongoing practical review; a valid alt attribute and a passing automated test do not constitute a complete WCAG certification.
Check copyright and approved brand assets
Images sourced from a search engine are not automatically free to reproduce. A thumbnail or competitor illustration may be visible online but still subject to copyright or licence restrictions. Prefer original work, licensed assets or source material with clearly documented reuse rights. Keep records of creators, permitted uses and any required attribution. Do not copy Hostinger or InMotion Hosting diagrams into OnHypp articles simply because their technical explanations are used as references. Write original descriptions and create distinct lawful visuals.
For a company brand, maintain a controlled set of approved logo originals and variants. The source image used in Organization schema should match the actual OnHypp identity; an unrelated screenshot, low-resolution avatar or generated approximation can weaken recognition. Distinguish the horizontal website wordmark from a square favicon if those are separately approved. Avoid using unofficial marks or inventing new colour values from a random image. The correct asset, context and rights matter more than aggressively increasing image counts.
Finish with a useful audit rather than a keyword checklist
For each important visual, record its source, purpose, visible page, file name, format, dimensions, alt treatment, nearby context, accessibility concerns and public URL. If it functions as a link, verify the accessible name describes the destination. If it is decorative, consider an empty alt. If it explains a process, ensure the same information is available in text. Check that the relevant article image is visible on the article page and that its sitemap association is accurate.
After a confirmed production release, inspect image responses over HTTPS, test the page with images disabled, review mobile rendering and use Search Console where appropriate to assess discovery issues. The goal is not to guarantee a picture appears in every result; Google determines previews. An OnHypp website should help Malaysian SME visitors understand services clearly, identify the official brand and navigate English or Malay content without losing information. Image SEO succeeds as part of that experience rather than as a substitute for it.